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

Robert Klemme wrote in post #1102170:
> 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添nicki
>

Sorry for late answer, busy day at work.

>>> 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] = method_instance.code, than
>> object[:method_name] = 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.

Well, you're right - my wording implied that existing behavior is 
somehow 'incorrect' or buggy, while certainly it works as intended. 
Sorry for this.

>
>>> 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/
>

Ah, it's nowhere near finished :-) I think that we should stick to 
greetings/curses problem, that's my problem distilled.

>> 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.

Yes, well, it's not that I want whole Ruby to be changed because of my 
whining. I guess what I was trying to ask was if there is some obvious 
solution that I overlooked (you know, kind of: "Geez, yet another rookie 
having problems with 'super'. Listen man, do yourself a favor and do it 
like this and this, it's been solved 1000 times before")


> 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.
>

I don't think so, I mean, obviously super already has to know the name 
of the method it's invoked from to do a lookup. The question is - where 
the name is taken from. If method used its "actual" name instead of 
"original" name then we're fine with super itself. An additional cost I 
can see lurking here is that define/alias method would need to copy a 
method instance (if called with one as an argument) and change its name 
to reflect aliasing, rather than just reference the original one. 
Anyhow, this is purely hypothetical.

BTW, having given it a little thought I think that I can easily check 
for the condition of being called from super myself. What it takes is 
just a flag that signals that we're recursively called and a check what 
real 'self' is. I still need to flesh out the details but I guess this 
might work.

-- 
Posted via http://www.ruby-forum.com/.