Email list hosting service & mailing list manager

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)

Re: complexity of mechanism felix winkelmann 13 Apr 2006 09:44 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