--- "David A. Black" <dblack / wobblini.net> wrote:
> 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....

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.

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

> > * 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 +=.

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.

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

I think this is a good example to show the difference. 
Programmers need to understand the difference shown above.  One
assigns to a variable and one assigns into an object that a
variable has.  Both are normal things you would want to do and
both are assignment-like.

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

Why do some of you think that everything I suggest has to do
with references?  The initial reason I was wanting this was in
my BNF like classes thing (specify syntax in Ruby directly
rather than in some other language - yacc/lex).  Right now I
have things like this:

int = (("0".."9")*(1..+1.0/0)).qualify { |m| m.to_s.to_i }

I use operator overloading quite a bit in this to create these
Syntax (renaming it to Grammar) objects.  In the example above,
int now is used to match anywhere from 1 to an infinite number
of digits and the resulting parse tree (an array of digit
characters) is converted to an integer.  In the above, it would
have been nice not to have to put the .qualify in there and
have it look like this:

int = (("0".."9")*(1..+1.0/0)) { |m| m.to_s.to_i }

That is where the idea originated.  Nothing to do with
references.

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

Good point.  It is similar to differentiating between a local
variable and a method call.  Doing the above would do the same
between a method call and calling the default method in an
object:

xyz - could be a local variable (default) or a method call
xyz() - could be a method call (default) or a null method call
(xyz)() - definitely a null method call

> I fear that's the
> slippery slope to what people call "write-only code".

You could argue that.  That is what Java designers said.  And
that is why they didn't allow operator overloading.  I think
operator is a good thing, but someone can easily abuse it and
make write-only code.  I think what I'm suggesting here is like
adding more operators.



		
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html