|
Re: complexity of mechanism
felix winkelmann
(12 Apr 2006 19:39 UTC)
|
|
Re: complexity of mechanism
Eli Barzilay
(12 Apr 2006 20:54 UTC)
|
|
Re: complexity of mechanism
felix winkelmann
(13 Apr 2006 06:43 UTC)
|
|
Re: complexity of mechanism
Eli Barzilay
(13 Apr 2006 07:07 UTC)
|
|
Re: complexity of mechanism
felix winkelmann
(13 Apr 2006 08:04 UTC)
|
|
Re: complexity of mechanism
Eli Barzilay
(13 Apr 2006 08:26 UTC)
|
|
Re: complexity of mechanism felix winkelmann (13 Apr 2006 09:44 UTC)
|
|
Re: complexity of mechanism
John Cowan
(13 Apr 2006 11:43 UTC)
|
|
Re: complexity of mechanism
John Cowan
(13 Apr 2006 11:52 UTC)
|
|
Re: complexity of mechanism
Eli Barzilay
(13 Apr 2006 12:58 UTC)
|
|
Re: complexity of mechanism
felix winkelmann
(13 Apr 2006 13:15 UTC)
|
|
Re: complexity of mechanism
Eli Barzilay
(13 Apr 2006 13:07 UTC)
|
|
Re: complexity of mechanism
feeley
(13 Apr 2006 14:07 UTC)
|
On 4/13/06, Eli Barzilay <xxxxxx@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",
remember?)
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).
cheers,
felix