From: "David A. Black" <dblack@...>
Date: 2005-05-19T02:59:40+09:00
Subject: Re: syntax sugar: treating an object like a method

Hi --

On Thu, 19 May 2005, Eric Mahurin wrote:

> I'm thinking of yet another RCR and would like to see if
> anybody likes it.  I think this would be a sweet feature.  Here
> are the basic components:

I'm not sure what the canonical definition of syntactic sugar is, but
I don't think that I think this is exactly that.  Anyway....

> 1. Allow a null/default method to be defined in a class so that
> the syntax "obj(*args,&block)" could be used.  obj could be any
> expression yielding a object.  When you try to treat that
> object as a method passing arguments and/or attaching a code
> block to it, the null/default method would be called.  I was
> thinking "@" would be a good name for this method - like "+@"
> and "-@".  Here are a few example uses:
>
> * klass(*args) : you alias the null method to "new" so that
> this would be equivalent ot klass.new(*args).  I tend to forget
> the ".new" more often than I'd like to admit.

Forgetting .new is a weak reason for making it optional.  It would be
hard to argue that calling MyClass.new to create a new MyClass object
is arcane or hard to get the hang of.

> * obj() : this could be aliased to clone in Object so that
> default would be to just obj.clone
>
> * enum {...} : you could alias the null method to "each" so
> that this would be equivalent to enum.each {...}
>
> 2. Allow an assignment method to be defined for an object ('='
> is probably best).  This would be called when you find an
> object expression on the LHS whereas #1 is the equivalent for
> the RHS.  The ugly thing about this is that you have to make
> sure that the object being assigned looks like an expression as
> opposed to a variable or attribute assignment - surrounding is
> parentheses makes it an expression that is normally illegal to
> assign to.  Along with '=', '+=', '-=', etc. becomes meaningful
> in this context.  You could also incorporate RCR 157/307 in
> there allowing arguments.  Here are a few example uses for
> this:
>
> * (str) = value : this could default to "replace" for any
> objects that respond to it (or if you use evil.rb - "become")
>
> * (mutable) += value : now the real += can be implemented for

+= is already the real +=.  It's not the C or Perl +=, but it's the
real Ruby +=.

> this since you are accessing the object rather than assigning
> the variable.  Of course Fixnum is immutable, so it doesn't do
> you any good there.  Other mutable classes (or ones that could
> be made mutable - Float) could take advantage of this (for
> example Array).

To a large extent, my reaction to all of these examples comes down, as
it often does, to the question: how would I explain this to someone to
whom I was teaching Ruby (in person or in writing)?  I think I would
find it quite difficult to explain that in this:

   s = "hi"
   t = s
   (s) = "bye"

t is now "bye".  I understand that there's really no such thing as
"intuitive" computer language syntax, but this seems to be pushing it
way in the other direction.  I just can't see how wrapping something
in parentheses can be hooked into any kind of explanation.  I mean, it
could be explained, just as ${var} = "hi" can be explained in Perl,
but I really believe that very few things in Ruby, if any, travel this
far from something reasonably self-evident to a reasonably large
number of programmers.

I also continue to be unconvinced of the need, usefulness, or
desireability of any of the extra level of reference kind of thing.

Similarly, obj() requires one to figure out whether or not there is a
method called obj, and if there isn't to try to figure out what has
been defined as () for this particular object.  I fear that's the
slippery slope to what people call "write-only code".


David

-- 
David A. Black
dblack@wobblini.net