Issue #15428 has been updated by shevegen (Robert A. Heiler).


Are you sure that .call had the same meaning as to_proc?

I vaguely remember the old pickaxe having mentioned .call a
lot, but I can not recall it having mentioned to_proc much
at all. It has been quite some years since I last had a look
at it though; obviously since ruby changes that also means
that the way we use ruby changes.

As for the lambda syntax and << - I think it would be better
to keep the proposals different if possible since at the 
least to me, ->(x) { y } << z looks ... very, very weird.

It would be better to keep the issue here about call versus
to_proc, in my opinion.

----------------------------------------
Misc #15428: Proc composition: what can quack like Proc?
https://bugs.ruby-lang.org/issues/15428#change-75770

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
I believe, that solution of #6284 introduced important language inconsistency: as far as I can tell, it insists that **anything that responds to `#call`** is composable, e.g. **quacks like `Proc`**.

The problem is, previously it was **never** this way. `#call` method has a nice shortcut of `.()`, but when you wanted to tell something can quack like proc, it **always** was done by defining `#to_proc` method.

I understand it could be too late to ask, but I wonder why this inconsistency was introduced and is there a plan to take this step further? 
For me personally, this `#call`/`#to_proc` dichotomy was always weird and feels like it needs some unification (maybe anything having `#call` will automatically have `#to_proc` method?), but the situation when exactly one language feature treats it differently looks pretty weird for me.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>