From: gabriele renzi Date: 2005-06-08T04:10:26+09:00 Subject: Re: making a duck Eric Mahurin ha scritto: > --- Robert Klemme wrote: > >>Eric Mahurin wrote: >> >>>--- nobu.nokada@softhome.net wrote: >>> >>>>At Tue, 7 Jun 2005 11:59:47 +0900, >>>>Eric Mahurin wrote in [ruby-talk:144750]: >>>> >>>>>Is there an advantage to having a separate Behavior class >>>> >>>>as >>>> >>>>>opposed the solution I had: making a singleton Object >>>> >>>>directly? >>>> >>>>To allow sharing same behavior. >>> >>>I'm not sure how much application this would have over the >>>conventional class definition approach. >>> >>>At first I didn't think this would work because I thought >> >>you >> >>>wouldn't be able to create any instance variables using >>>define_method. I thought any @ variables in a proc would >> >>refer >> >>>to the @ variable in the original context, but >> >>define_method >> >>>apparently rebinds them to the object. >> >>I always remind myself that the binding of "self" changes - >>even for each >>method invocation. This explains pretty good why this works >>as it should. > > > define_method, instance_eval, class_eval, module_eval, and > maybe others seem to have this special ability - rebind the > meaning of self (but not locals) for a Proc. I think of self as a dynamic variable, outside of lexical scope and that makes me think.. > This brings us > back to the topic I talked about earlier - unbind/rebind procs. > It would be nice if we could do the same thing to a Proc that > these methods can do internally ... would dynamic variables be enough? Christian Neukirchen has a nifty implementation of them on his blog. > BTW, I don't see the value that class_eval and module_eval > provide over instance_eval. classes and modules can be treated > like instances just like any other object. if you define a method in a class_eval/module_eval block on object X ruby will define it in instances of X while if you use instance_eval you'd define the method on the object X