syntax sugar: treating an object like a method

[Eric Mahurin]

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:

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.

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


I was mainly wanting #1, the complementary #2 looks pretty
useful too.




__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail

 

[Brian Schröder]

[snip]
* 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.
[snip]

I don't know if I like this proposal, but in any case I'd expect a syntax l=
ike:

class A
def initialize(x)
@x =3D x
end
=20
def self.[](x)
self.new(x)
end
=20
def self.()(x)
self.new(x)
end
end

A[12]
A(12)

for it. (Note that the square brackets already work.)

best regards,

Brian

--=20
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

 

[David A. Black]

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

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.

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

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"

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.

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. I fear that's the
slippery slope to what people call "write-only code".


David

 

[Austin Ziegler]

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:

Please don't. This would be awful. Ruby doesn't need a () operator.

-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[ES]

Please don't. This would be awful. Ruby doesn't need a () operator.

Oh, never say never. I still fantasize about first-order functions/
methods (although that need would probably be better served by other
means). For this particular purpose I would tend to agree, though.

-austin

E

 

[Austin Ziegler]

Oh, never say never. I still fantasize about first-order
functions/ methods (although that need would probably be better
served by other means). For this particular purpose I would tend
to agree, though.

As I understand it, Ruby already has first-order functions; they're
just not (currently) callable with foo(). Ruby 1.9 has an
experimental change that does this for local variables that have
Methods or Procs in them.

At the very least, no one has been able to explain to me why what
Ruby does isn't acceptable. I don't want or need Ruby to be Python
and I don't want or need a () operator.

-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[gabriele renzi]

Austin Ziegler ha scritto:

As I understand it, Ruby already has first-order functions; they're
just not (currently) callable with foo(). Ruby 1.9 has an
experimental change that does this for local variables that have
Methods or Procs in them.

AFAIK it does work (reasonably to me) for everything that has #call.

At the very least, no one has been able to explain to me why what
Ruby does isn't acceptable. I don't want or need Ruby to be Python
and I don't want or need a () operator.

it *is* acceptable, *I* would just prefer some syntax sugar.
I mean,
x.foo()
is quite acceptable but I think
x.foo
is nicer.

 

[Paul Brannan]

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:

These really sound like two separate change requests to me.

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.

* 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 {...}

What you propose requires a change in name lookup rules. I suggest you
consider what the current rules are and what you would like them to be
before you submit an RCR.

Also, consider that Ruby already has a mechanism for callable objects;
any object that is callable responds to the call() method (consider
Proc and Method).

Paul

 

[ES]

As I understand it, Ruby already has first-order functions; they're
just not (currently) callable with foo(). Ruby 1.9 has an
experimental change that does this for local variables that have
Methods or Procs in them.

First-order method meaning here that methods are just a special
case of a block that has been bound to a particular object. They
would be fully rebindable, copyable and assignable. Essentially,
in a way, simply method dicts.

At the very least, no one has been able to explain to me why what
Ruby does isn't acceptable. I don't want or need Ruby to be Python
and I don't want or need a () operator.

What Ruby does is perfectly fine. True first-order would yield some
more flexibility.

-austin

E