From: "Florian Groß" <florgro@...>
Date: 2006-04-09T23:14:23+09:00
Subject: Re: yield, binding

dblack@wobblini.net wrote:

> I'm hoping there won't be too many of these "you just have to know it"
> things in 2.0.  Yes, Matz, I trust you!  But there's been talk, at
> least, of send vs. funcall, and instance_eval vs. instance_exec, both
> being pairs of methods that do similar things but whose names don't
> tell you which is which.  It's easy for experienced Rubyists to
> remember that "the new one is the one that does new stuff", but I
> think that even a little of this could make learning Ruby a lot
> harder.
> 
> Then again, I can't think of any perfect names (well, I liked send and
> send! but Matz didn't :-) so I should shut up.

Agreed, I also think changing the semantics of send() should be avoided. 
I'd have preferred introducing a version that has the access checks.

I do not even really like the name funcall().

Hm, perhaps redispatch()? forward()?

Perhaps send() could be able to call private methods if it isn't called 
with a receiver. That would allow for obj.instance_eval { send(:foo) }. 
Sounds somewhat obscure, though.

Sometimes I wonder if it would be better to just start using argument 
distinction a lot more.

lambda(:semantics => :block) { ... }
# Though I still prefer having a lambda(arg, *args) { } syntax for
# method semantics
lambda(:semantics => :method) { ... }

obj.send(:private, :function, ...)
obj.send(:public, :function, ...)
# OTOH mod.send(:private, :private, ...) is *very* odd

If Object#method would return a wrapper in case method_missing() is used 
one could do obj.method(:foo).call for calling private methods.

I do not really have a better suggestion for how to do this. I just 
wonder if send() being able to call private methods is really a problem.

I agree with you that differences you just have to know are a very bad 
thing. I like to distinguish different things with clear names.

Being a language designer isn't an easy job at all, I guess. Always 
needing to balance between the past and the future will make things very 
complex. And there's a lot more you need to keep balanced as well.

-- 
http://flgr.0x42.net/