From: "trans.  (T. Onoma)" <transami@...>
Date: 2004-10-06T03:17:39+09:00
Subject: Re: Subclassing Binding

On Tuesday 05 October 2004 02:00 pm, Paul Brannan wrote:
> On Tue, Oct 05, 2004 at 12:10:08AM +0900, trans.  (T. Onoma) wrote:
> > Short answer:
> >
> >   class TracePoint #< Binding
> >
> >     def initialize(event, binding, back_binding=nil)
> >       @event = event
> >       @binding = binding  # delegate!!!
> >       @back_binding = (back_binding ? back_binding : binding)
> >     end
>
> This doesn't really answer my question well.  Why do you want to inherit
> from binding here instead of delegating to it?  Delegation in Ruby is so
> easy that it's often preferred over inheritance.

Okay, well, delegation works okay. At least I don't see any significant 
drawbacks --albeit there may be some subtle distinctions I am not aware-of. 
So really, the point is simply that a TracePoint is "formally" supposed to be 
a Binding. That's all.

BTW, robert pointed out that this improvement over the above:

    def initialize(event, bind, back_binding=bind)
       @event = event
       @binding = bind
       @back_binding = back_binding
     end

Also, I should point out that the back_binding exists because a set_trace_func 
'return' event gives a binding outside to the returning method, rather then 
inside of it. I guess this is how it's supposed to be, but for many purposes 
the inner binding is still needed. It would be nice if set_trac_func dealt 
with this. Actually what I will eventually propose is that set_trac_func use 
TracePoint instead, as well as a Kernel#call_stack method. --one of the 
important things I realized was that a Binding actually carries all the other 
info trace_set_fuc returns, except for the event type.

T.