Re: Finding one's way with 'super' in define_method/alias_emthod

On Mon, Mar 18, 2013 at 8:39 PM, Marcin R. <[e-mail]> wrote:
> Robert Klemme wrote in post #1102151:
>> On Mon, Mar 18, 2013 at 5:50 PM, Marcin Rze=C5=BAnicki

>>> You can see it clearly
>>> when inspecting the caller - in both cases it is 'greetings'. While
>>> this may seem logical and sound, it is quite troubling when you try to
>>> make a wrapper method around user-defined method doing metaprogramming
>>> tricks.
>>
>>> Do you know any workaround? How can I overcome this problem and let
>>> super be bound correctly if used from aliased method? Thanks in
>>> advance for your opinions.
>>
>> I am not sure what you expect should be called "bound correctly".
>> Basically what you did is you said D#curse should be D#greeting
>> (either via define_method as shown above or alias).  That means, D's
>> method #curse behaves like D's #greeting and hence ultimately invokes
>> C#greeting and not C#curse.
>
> When I imagine hypothetical pseudo-code implementation of define_method
> I'd rather see: object[:method_name] =3D method_instance.code, than
> object[:method_name] =3D method_instance :-)

Your expectation was clear.  But others may have different
expectations.  We are discussing to try to find out what might be more
reasonable or what expectations might be shared by more people. :-)
That's why I questioned whether the term "correctly" was appropriate
here.

>> Btw, somehow your chain example seems incomplete: is #chain a method
>> defined in Module?  What about method names?  I would have expected
>> the chained method name to be given as argument.
>
> Ah yes, I omitted lots of details for brevity, trying to get to the
> bottom line, if you will. Basically, chain is called from method_added
> hook. When you include the module it installs this hook, adds class
> method to specify the name of a "chained" method, listens for
> subclassing to get into child class to do the trick again etc., but I
> felt that this boilerplate was irrelevant to my problem.

Maybe you left out too many details. :-)  It usually helps to provide
a small and above all complete example that others can execute:
http://sscce.org/

>> I once coded something together for wrapping methods - you may find it
>> in the archives.  I am not sure though that I still have the code
>> elsewhere...  I only found this one:
>> https://gist.github.com/rklemme/3002732 but that's not the one I mean.
>
> I will certainly try to find it. Many thanks. BTW, judging from example
> you posted (I have not yet run it, though) it exhibits the same problem
> as my implementation - calling super from #_m would call #m in parent
> class which could call #_m in child again.

Yes, super and alias don't mix well.  You could argue that a method's
behavior would change depending on the name used to invoke it if Ruby
was made to match your expectation.  There are two downsides:

1. Could be viewed as an aesthetic issue: the behavior of code would
change after the definition of the method.
2. As a consequence of changed behavior there would be a runtime
effect: while executing the interpreter would have to have knowledge
of the name used to invoke a method.  Now you could argue that this
knowledge does actually exist (caller provides it) but it may incur a
runtime hit - for just a small amount of use cases.

Redefining a super class method also affects what code "super" will invoke:

irb(main):001:0> class A
irb(main):002:1> def x; p 1 end
irb(main):003:1> end
=3D> nil
irb(main):004:0> class B < A
irb(main):005:1> def x; p 2; super end
irb(main):006:1> end
=3D> nil
irb(main):007:0> B.new.x
2
1
=3D> 1
irb(main):008:0> class A
irb(main):009:1> alias _x x
irb(main):010:1> def x; p 3; _x end
irb(main):011:1> end
=3D> nil
irb(main):012:0> B.new.x
2
3
1
=3D> 1
irb(main):013:0> A.new.x
3
1
=3D> 1

And then there is the issue that you can invoke a method without a
name.  What method would super invoke in that case?

irb(main):024:0> m =3D B.instance_method :x
=3D> #<UnboundMethod: B#x>
irb(main):025:0> b =3D B.new
=3D> #<B:0x88d0f38>
irb(main):026:0> m.bind(b).call
2
3
1
=3D> 1

With a slightly different experiment you can see that aliasing a
method just creates a second reference to the same code:

irb(main):001:0> class X
irb(main):002:1> def x; caller 0 end
irb(main):003:1> alias y x
irb(main):004:1> end
=3D> nil

irb(main):006:0> puts X.instance_method(:x).bind(X.new).call
(irb):2:in `x'
(irb):6:in `call'
(irb):6:in `irb_binding'
/usr/lib/ruby/1.9.1/irb/workspace.rb:80:in `eval'
...
irb(main):007:0> puts X.instance_method(:y).bind(X.new).call
(irb):2:in `x'
(irb):7:in `call'
(irb):7:in `irb_binding'
/usr/lib/ruby/1.9.1/irb/workspace.rb:80:in `eval'
...

Even for such a seemingly simple case if one goes beyond one's
expectations things are more complex than they seem on initial sight.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/