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
