Forum: Ruby-core [ruby-trunk - Feature #7346][Open] object(.) as syntax sugar for object.call(.)

Issue #7346 has been reported by rosenfeld (Rodrigo Rosenfeld Rosas).

----------------------------------------
Feature #7346: object(...) as syntax sugar for object.call(...)
https://bugs.ruby-lang.org/issues/7346

Author: rosenfeld (Rodrigo Rosenfeld Rosas)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: Next Major


I propose for the parser to interpret "object(...)" as 
"object.call(...)". It should raise NoMethodError at runtime if object 
doesn't respond to "call".

This would read better than using "call":

double = -> n { n * 2 }

double(3) == 6

Sorry if this has already been proposed before (and rejected) but I 
couldn't find any references to something like this using Redmine's 
search interface.

Issue #7346 has been updated by matz (Yukihiro Matsumoto).

Status changed from Open to Rejected

I have once tried, but it caused serious incompatibility problem for 
example:

  p = Object.new
  p(15)

So compromise with object.() syntax introduced in 1.9.

Matz.

----------------------------------------
Feature #7346: object(...) as syntax sugar for object.call(...)
https://bugs.ruby-lang.org/issues/7346#change-32857

Author: rosenfeld (Rodrigo Rosenfeld Rosas)
Status: Rejected
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: Next Major


I propose for the parser to interpret "object(...)" as 
"object.call(...)". It should raise NoMethodError at runtime if object 
doesn't respond to "call".

This would read better than using "call":

double = -> n { n * 2 }

double(3) == 6

Sorry if this has already been proposed before (and rejected) but I 
couldn't find any references to something like this using Redmine's 
search interface.

Issue #7346 has been updated by rosenfeld (Rodrigo Rosenfeld Rosas).


Ah, ok, I didn't know about this syntax until now. What does the code 
above do?
----------------------------------------
Feature #7346: object(...) as syntax sugar for object.call(...)
https://bugs.ruby-lang.org/issues/7346#change-32858

Author: rosenfeld (Rodrigo Rosenfeld Rosas)
Status: Rejected
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: Next Major


I propose for the parser to interpret "object(...)" as 
"object.call(...)". It should raise NoMethodError at runtime if object 
doesn't respond to "call".

This would read better than using "call":

double = -> n { n * 2 }

double(3) == 6

Sorry if this has already been proposed before (and rejected) but I 
couldn't find any references to something like this using Redmine's 
search interface.

Issue #7346 has been updated by matz (Yukihiro Matsumoto).


We easily forget conflict between method names and variable names, in a 
language like Ruby, where methods and variables have separated name 
space.

We expect p(15) to print 15 even when we have a variable named p in the 
scope.

Matz.


----------------------------------------
Feature #7346: object(...) as syntax sugar for object.call(...)
https://bugs.ruby-lang.org/issues/7346#change-32859

Author: rosenfeld (Rodrigo Rosenfeld Rosas)
Status: Rejected
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: Next Major


I propose for the parser to interpret "object(...)" as 
"object.call(...)". It should raise NoMethodError at runtime if object 
doesn't respond to "call".

This would read better than using "call":

double = -> n { n * 2 }

double(3) == 6

Sorry if this has already been proposed before (and rejected) but I 
couldn't find any references to something like this using Redmine's 
search interface.

Issue #7346 has been updated by rosenfeld (Rodrigo Rosenfeld Rosas).


Ah, of course! :D I totally forgot about Kernel#p! :P

Yes, that makes total sense.
----------------------------------------
Feature #7346: object(...) as syntax sugar for object.call(...)
https://bugs.ruby-lang.org/issues/7346#change-32860

Author: rosenfeld (Rodrigo Rosenfeld Rosas)
Status: Rejected
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: Next Major


I propose for the parser to interpret "object(...)" as 
"object.call(...)". It should raise NoMethodError at runtime if object 
doesn't respond to "call".

This would read better than using "call":

double = -> n { n * 2 }

double(3) == 6

Sorry if this has already been proposed before (and rejected) but I 
couldn't find any references to something like this using Redmine's 
search interface.

@rosenfeld, I'll just mention that you can use Proc#[] in your example:

double = -> n { n * 2 }

double[3] == 6  #=> true

Issue #7346 has been updated by rosenfeld (Rodrigo Rosenfeld Rosas).


Yes, I know, it is just that I prefer to read object.call(arguments) 
than object[arguments]. This is just a personal opinion, I know and I 
can change my mind some day about this :)
----------------------------------------
Feature #7346: object(...) as syntax sugar for object.call(...)
https://bugs.ruby-lang.org/issues/7346#change-32875

Author: rosenfeld (Rodrigo Rosenfeld Rosas)
Status: Rejected
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: Next Major


I propose for the parser to interpret "object(...)" as 
"object.call(...)". It should raise NoMethodError at runtime if object 
doesn't respond to "call".

This would read better than using "call":

double = -> n { n * 2 }

double(3) == 6

Sorry if this has already been proposed before (and rejected) but I 
couldn't find any references to something like this using Redmine's 
search interface.