From: Eric Mahurin <eric_mahurin@...>
Date: 2005-05-19T06:15:39+09:00
Subject: Re: syntax sugar: treating an object like a method

> > > 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....
> > 
> > In my book, syntactic sugar is when you have a more
> > concise/readable syntax that is equivalent to a more
> > fundamental (and longer) syntax.  So by that definition,
> all of
> > the operators that equate to methods are syntactic sugar. 
> I
> > think this thing I'm talking is similar to adding another
> > operator.
> 
> I think the key element is that syntax sugar should shorten
> the syntax,
> but should _not_ have the side-effect of making two very
> similar pieces
> of well-known code to behave differently - which is what it
> looks like
> in this case. 

I guess you are referring to the fact that "calling" an object
(using a would the "null" method) looks similar to calling a
method.  You would have to figure out which is which.  You'd
get an error now by "calling" an object, so there would be no
compatibility issue.

From that qualification I guess a simple method call with no
args (or parens) would not be syntactic sugar to you since it
also looks like a local variable.  I still consider it sugar,
but I guess you don't.

> > > > 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.
> > 
> > I know it is weak.  But, it did seem to prod me to develop
> this
> > idea a little more - because the vast majority of time the
> only
> > thing you do with a class is call new.
> 
> I'd agree that most users will just want Class.new most of
> the time, but
> it's pretty standard amongst languages these days and helps
> us
> distinguish that "yeah, he's creating a new instance of the
> class
> there". Beyond that, what if I actually wanted a handle on
> the class and
> to assign the class to a variable. Do we add syntax for that
> now?
> 
> 
> > > > * (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 +=.
> > 
> > Correct.  "real" was the wrong word.  How about "in-place"?
>  A
> > normal += in Ruby creates a new object whereas this one
> > modifies an object in-place.
> 
> Following our already established "in-place" method naming
> convention,
> it'd actually be "=!" which would make me mistake it for "!="
> way too
> often. And the subtle parentheses around the variable is way
> too
> confusing.
> 
> In short, I don't see a great need for these,

There definitely is not a great need for this syntax since it
just makes some code more concise (and maybe prettier).  That's
why I call it sugar.

> and I think the
> syntax
> differences are too subtle and will lead to everyone
> scratching their
> heads wondering why their code is behaving so oddly...

I won't argue with that.



		
Discover Yahoo! 
Stay in touch with email, IM, photo sharing and more. Check it out! 
http://discover.yahoo.com/stayintouch.html