[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: complexity of mechanism
On 4/13/06, Eli Barzilay <email@example.com> 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
> (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)
(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).