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