At 10:13 AM +0100 8/8/02, Nicholas Clark wrote: >On Thu, Aug 08, 2002 at 10:21:54AM +0200, Peter Gibbs wrote: > > Should a PerlScalar have its own vtable which acts as appropriate >> depending on current content, or should it switch vtables as the >> content changes? If the latter, do we have separate vtables for >> e.g. PerlInt versus PerlScalarContainingAnInt, or do we use the >> same PerlInt vtable, but have a separate 'real type' somewhere in >> the PMC, for use by set_pmc (and anybody else that needs to >> behave differently) ? > >Is it possible for any parrot code to spot the difference between these >three? I think the middle suggestion (switching to the PerlInt vtable >when an int is assigned) isn't going to work, as the next time a floating >point (or string) value is assigned to that PMC, the PerlInt vtable will >coerce the incoming value to an int. Which isn't correct. >I think the other two are (or should be) indistinguishable in behaviour, so >then it comes down to speed and maintainability. But I could be wrong.
We can do one of two things: 1) Either have separate PerlInt/Num/String classes that differ from the PerlScalar class or 2) Have a flag that governs whether a PMC should upgrade or not. Both make sense--there are times when PMCs should be of fixed type and times when they shouldn't. I think we'll eat up one of the PMC flags for this. We need to differentiate between PMCs that are a type because of declaration and PMCs that are that type because of sheer happenstance, if nothing else. -- Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk