Hi --
> 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
···
--- "David A. Black" <dblack@wobblini.net> wrote:
On Thu, 19 May 2005, Eric Mahurin wrote:
