On Fri, 29 Dec 2006, Trans wrote:

>
> ara.t.howard / noaa.gov wrote:
>> since the threads split all over the place i figured i'd start yet another.
>> can people break this?
>>
>> [snip code]
>
> Aren't you leaving residual emtpy modules behind when you ermove
> methods?

not really.  basically the first call to override sets up a master parent
module with the orginal methods


   object -> [master]

and re-definition takes place in a module between the object and this master,
thus super works

   object -> [redef] -> [master]

subsquent redefs chain like so, preserving super semantics

   object -> [redef 2] -> [redef 1] -> [master]

note that the modules are created not once per method, but once per call to
'override'.  therefore this

   class C
     def a() 'a' end
     def b() 'b' end
     def c() 'c' end

     override{
       def a() super.upcase end
       def b() super.upcase end
       def c() super.upcase end
     }
   end

creates exactly two modules: the master and one redef.  now if we do this

   class C
     override{
       def a() super.downcase end
       def b() super.downcase end
       def c() super.downcase end
     }
   end

we've created just one more.  something like

   object -> [redef 'downcase'] -> [redef 'upcase'] -> [master]

now, say we do this

   class C
     restore{
       a and b
     }
   end

then __only__ the methods 'a' and 'b' from [redef 'downcase'] are removed.
the 'c' method still lives there.


so, while it is a true statement that __each__ call to 'override' introduces a
new mixin module, it is not true that __every__ call to 'restore' leaves an
extraneous module mixed in, though it's possible that a given call to
'restore' may indeed have that effect.

make sense?

-a
-- 
if you find yourself slandering anybody, first imagine that your mouth is
filled with excrement.  it will break you of the habit quickly enough. - the
dalai lama