Berger, Daniel wrote:

> > Amen. As I keep saying, it's a matter of interface. If you allow
> > implicit keyword arguments, you're suddenly mixing interface and
> > implementation, and that is *wrong* (in the sense that it is
> > difficult to maintain, and it breaks the promise of encapsulation).
> > However, if you explicitly decide that some argument is a keyword
> > argument, you have *consciously* made it part of the interface (I'd
> > rather say part of the very *name* of the method), so you can still
> > maintain the separation between interface and implementation to the
> > level you want as a developer.

> The separation between implementation and behavior you make here is
> lost the moment you commit to supporting a keyword argument for any
> given method, regardless of the fact that it was an explicit,
> conscious choice.  Once chosen, you're still beholden to that keyword
> name forever unless you want to break backwards compatability.  I
> think the perceived freedom is an illusion.
> 
> There seems to be this fear of using an argument name, and then later
> changing your mind about what the argument name should be called.  To
> that I reply that, even with the explicit syntax, this issue does not
> go away.  I would also say that all the implicit syntax does is force
> you to think more up front about your API and naming conventions.
> With Sydney, at least you can resort to positional parameters in the
> unlikely event that the argument name did change, something you can't
> do with Matz's current proposal afaik.

I”Ēm not pretending to understand what the whole discussion is about, but
as far as I understand, keyword arguments for Ruby as suggested by matz
are very much like those found in Common Lisp.  I don”Ēt see them having
a hard time using them.  I think that the way keyword arguments are used
in Common Lisp makes a lot of sense.  Give mandatory arguments as
positional arguments and then pass in any optional arguments as keyword
arguments in any order you see fit, e.g., the find function in Common
Lisp:

  find-if predicate sequence &key from-end start end key => element

OK, the two first arguments are always going to be a predicate that we want
to test with, and a sequence we want to traverse.  Then we have
optionaly keyword arguments that narrow the search, if we are so
inclined.  I don”Ēt see the point of naming every argument that we pass
around.

        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}