> Great. However, I also want the end-user of this library to be able
> effect all classes and modules with a single extend (or include) as
> well, if they so choose. Eg.
> class Module
> include MyEnhancement
> end
Is the problem here that Module defines its own #attr_accessor
shadowing the new one?
Yes, that's part of the issue here. In the case where one extends a
class, #super works, in the case of including it into Module, one had
to do the whole alias chaining thing.
As I worked on this it made me think that it would be nice if their
were a MetaKernel for the Module's methods, just as there is a Kernel
for Object's methods. That would at least DRY this part up.
> It would also be nice if the module's methods can be made to work from
> the toplevel (main):
> extend MyEnhancement
What should #attr_accessor do in the context of the toplevel object?
Maybe you can show us another example?
What it normally does, define a method wrapping an instance variable.
Having it at toplevel isn't that important in this case. But I have a
similar case for an original method (#annotator) where it is.
If the toplevel object were a self extended module, this would not be
an issue either. I know I've brought this up more than a few times,
but I don't recall Matz ever addressing it, and saying why it's not a
good idea. Sure wish I knew, with all the meta-coding I've done this
is one of the few issues I keep bumping my head against.
> In attempting to implement this, I have found myself resorting to
> unDRY, ugly, hacky code, that always seems to have a bug in it
> somewhere. It's infuriating. This is not how programming Ruby is
> supposed to be!
Hmm, I think this will be hacky indeed.
Unfortunately, what I've managed to get to work very much is. You can
see my hacks for the real deal here:
http://anise.rubyforge.org/git?p=anise.git;a=tree;f=lib/anise;h=d64d5a9ecef1c1b8e1c76a7d84c8462f3aad7ee6;hb=HEAD
Thanks,
T.
···
On Feb 15, 9:49 am, Pit Capitain <pit.capit...@gmail.com> wrote:
2009/2/15 Trans <transf...@gmail.com>: