[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: complexity of mechanism

On 4/13/06, Eli Barzilay <eli@barzilay.org> wrote:
> >
> > It seems you're trying violently to misunderstand me:
> (You keep contradicting your own argument.  At least IMO.)

Not at all. But this is getting boring, don't you think? Ok, just
one more time:

1) keyword arguments are useful, as a quick+dirty solution (you
  cited a sentence by Joe Marshall containing the word "hack",

2) This doesn't make them automatically good enough of what I consider
  as a SRFI, which should be of a higher standard (our opinions
  may differ here).

> > it's *too* easy: you quickly end up with a small set of functions
> > with loads of keyword parameters and yet another open manual to
> > consult.
> OK, consider what users need to know for a second.  With common Scheme
> code, if you want to extend a function in a way that doesn't break
> existing code, you add optional arguments.  Say you begin with
> something like:
>   (message-box <title> <prompt>)
> You then extend it with (in this order) a csutomizable button-spec
> ('yes-no, 'ok-cancel, 'ok, default is 'ok), timeout (number of
> seconds, or #f for no timeout), whether the dialog is on top of the
> main application or not (defaults to #t), and a bgcolor (defaults to
> (system-bg)):
>   (message-box <title> <prompt> [buttons] [timeout] [on-top?] [bgcolor])
> The defaults are the same as the original version -- so no change
> needed there.  Now you want to pop a blue message box, what do you do?
>   (message-box "title" "prompt" 'ok #f #t "blue")
> ...and you need to read through that whole paragraph above to do this.
> This is in contrast to
>   (message-box "title" "prompt" :bgcolor "blue")
> with no knowledge of the rest.  You'll always need the manual, but you
> don't need to read it through to just change the bgcolor.

(Eli, I know the difference between optional and keyword arguments,
there is no need to explain the rationale of SRFI-89 to me again. I've
read the document)

What about:

(message-box <title> <prompt> [<config-object>]) ?

Configuration-objects could be composed, inherited,
modified by accessors, whatever. I claim such an interface is
cleaner, possibly less verbose and likely to be more efficient.

And, if you desperately need it, use symbols as keywords and
roll your own: (message-box 'title "hello" ...). No need for
a distinct keyword type or ugly #! lambda-list markers (and a subsequent
overcomplication of lamba-list processing).