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
> ... That's needed for redispatching, in
> case a method decides it needs to continue the hierarchy search.
Ok, that should work.
> The methods themselves, though, have either been compiled into a
> class (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. OTOH its suboptinal for the static
case, e.g. all classes in one file. 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?
> There's a lot of compile-time data visiblity/hiding stuff implied in
> the current system that we're assuming but not enforcing at the
> parrot level. I'll beef up the explanation in PDD15.
Good, thanks. Its probably a definition, just how private are
attributes.
leo
