Re: method names in 1.9

On Mon, Nov 12, 2007 at 11:15:54PM +0900, Jordi wrote:
> Object.method () have different behaviour than send. It doesn't use
> method_missing. when it makes a lot of sense to use it. That behavior
> should be deprecated.
> object_a.send ("method_a")
> object_a.method(:method_a).call
> should be equivalents

That'd be a pretty radical change, considering that method_missing works by=
=20
side effect. In the absence of the side effect-free variant of method_missi=
ng=20
I mentioned earlier in this thread, you'd have to implement this new=20
Object#method (here #mm_method for "method_missing method") sort of like th=
is:

  class Object
    def mm_method(sym)
      if respond_to?(sym)
        method(sym)
      else
        lambda {|*args| send(sym, *args) } end
      end
    end
  end
 =20
  b =3D Object.new
  def b.frob() 'b frobbed' end
  m_frob =3D b.mm_method(:frob)
  # =3D=3D> Method
  m_prod =3D b.mm_method(:prod)
  # =3D=3D> Proc
  m_prod.call
  #! NoMethodError: undefined method 'prod'
  def b.method_missing(*args) "method_missing: #{args.inspect}" end
  m_prod.call(1,2,:z)
  # =3D=3D> "method_missing: [:prod, 1, 2, :z]"

I can definitely see the benefit to this approach of lazily resolving metho=
ds,=20
but I also don't think it's Object#method. I see that method as an=20
introspection and metaprogramming tool more than anything else.

At least in theory, Ruby provides two different interfaces to objects: an=
=20
abstract message-passing system (foo.bar) that conceals implementation=20
details, and a concrete system that exposes them (foo.method(:bar)). Both a=
re=20
heavily used.

The main issue seems to be that Object#send exists between the two systems=
=20
when it should properly fit within the first. Personally, I think that shou=
ld=20
be changed -- I do have some code which relies on #send calling protected=
=20
methods, but very little, and it's always been something of a hack.

--
Matthew Boeh