Re: Closures versus objects

On 2/16/07, Matt Hellige <[email protected]> wrote:
> On 2/16/07, Joe Marshall <[email protected]> wrote:
> > But Ruby syntax has a major disadvantage!  Suppose you wanted to late-bind the
> > method name?  In Scheme you'd do this:
> >
> > (let ((method   (select-method  len first last)))
> >   (method "abcd"))
> >
> > but you can't bind the name of a method identifier in Ruby:
> >
> >   method = select-method (len, first, last)
> >   s = "abcd"
> >   s.method
> >
> > won't work.
>
> To be fair, the ease of this kind of thing is usually considered a
> major advantage of Python, Ruby and friends:
>
> method = "length"
> s = "abcd"
> s.send(method)

I was unaware of this trick in Ruby.  It certainly won't work in C++ and would
be pretty cumbersome in Java.

In any case, it isn't quite the same as what I was suggesting.  In
this workaround
you are manipulating the name of a method, not the method itself.

> It's clear to me that literal method names (length) and
> variables holding method names (method) should appear different in
> code.

I don't know what you mean here, but on the face of it I disagree strongly.

If methods are named differently than variables, then you have
introduced another
namespace in which to resolve identifiers.  If you have multiple namespaces, you
then need a way to select which namespace you wish for resolution.  If that
selection is implicit (for instance, the name after the dot is always
resolved in
the method namespace of the object referred to), then you have to resort to
funny code to get around the implicit naming.  This usually throws a monkey
wrench into referential transparency.  On the other hand, if the namespace
selection is explicit, you end up cluttering your code with namespace
specifiers.

It seems to me that the language should provide a single, unified mechanism for
naming (that is, variables) and one should avoid introducing extra
ad-hoc mappings
(like resolving strings into method objects through reflection).

> It's also clear to me that calling literal method names is so
> overwhelmingly the norm that there should be convenient syntax for it.

The function call syntax is good choice.

> It seems to me that Ruby and ilk find a good balance here.

I disagree.  Manipulating names as first-class objects is confusing.

-- 
~jrm