> > 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