Dan Sugalski <[EMAIL PROTECTED]> wrote:At 11:09 AM +0100 2/27/04, Leopold Toetsch wrote:makes me wonder, ifn't such method functions should get a PMC of the class, for which the method was called
Yes... and no.
The class in which the method was found does have to be noted. I stuck a slot in the interpreter struct for it at one point recently, but I'm not sure it survived.
Yes its there: interpreter->ctx.current_class_offset
Good. (I think--that may end up being insufficient)
> The methods themselves, though, have either been compiled into aclass (in which case they already know what class they are) or are generic in which case they shouldn't be touching any attributes of the object, since only methods that were compiled into a class should be able to see that class' attributes.
So my example test code is bogus.
Yep. :)
OTOH its suboptinal for the static case, e.g. all classes in one file.
Well... no, not really. Partly because if you're using classes you're probably multi-file anyway, but mostly because I don't see how being in a single file makes any difference.
Please have a look at t/pmc/objects_25.pasm.
And do we never have to refer to %self{__CLASS__} or such in a method?
Not that I know of, no. You know at compile-time what class you're in, so it's not like this is really necessary. I can see a case where you might want to know what namespace a method came from if someone's installed it externally, but for attributes that won't matter (as they shouldn't be looking) and I'm more than willing to put it off until later.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
