On Fri, May 25, 2012 at 11:36 PM, Stevan Little <stevan.little@iinteractive.com> wrote: > I think you might run into a circularity issue with fetchmethod and ref being actual methods (how can fetchmethod fetch fetchmethod?), but this is the compromise of bootstrapping, so perhaps you make this a function call instead, after which you can make a method called fetchmethod that could call it (with some protections for infinite looping of course). We actually do something like this in the p5-mop internals for executing methods [1] but it does get a little messy (and mind-numbing at times). I was thinking on a much lower level than that, at lowest C level, so circularity shouldn't be an issue unless an implementation is implemented in Perl using itself. Currently method lookup is defined in the core roughly 1) Get stash 2) Lookup method for that stash I'd like that to change that 1) Get meta thingie 2) Lookup method in thingie. At first sight, introducing this indirection seems simple. The complicated part is other places that make assumptions about the presence of stashes on objects. > Inheritance can be tricky, so either the vtable structure itself needs to know about it (which is the case with most vtable implementations) or the vtable needs to get locked at some point so that it can flatten out the inheritance hierarchy. Again, we are doing something similar in the p5mop in how we are using Package::Anon [2]. I can imagine. This is obviously something that needs to be thought out well. LeonThread Previous | Thread Next