Williams, Chris
5/18/2005 8:29:00 PM
> > 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.
> > > 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, 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...
Chris