Syntax sugar: treating an object like a method

ruby-talk
1

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

So procs and methods are getting the () operator? Somebody
must be thinking similar. It seems like it would be easier to
implement the () operator than handle procs/methods specially.
And cleaner.

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.

I didn't know Python had that. Just found it:

x(arg1, arg2, ...) is a shorthand for x.__call__(arg1, arg2,
...)

ยทยทยท

__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

2

Eric Mahurin ha scritto:

I didn't know Python had that. Just found it:

x(arg1, arg2, ...) is a shorthand for x.__call__(arg1, arg2,
..)

but notice that python does not have (and never had) separate namespaces for methods and variables, like we have in ruby.
Special casing #call (which is something I like) will cause some breakage in cases where you do things like
  meth = meth(meth)
or similar, see a recent message from Joao Pedrosa (IIRC) that shows some examples of real libraries getting an error.