[RfC] Fix assigned PMC enum_class_xxx
Leopold Toetsch
fix assigned PMC class enums too. (Changed class enums invalidate
existing PBC files).
1) lib/Parrot/PMC.pm is the canonical source of PMC class => enum mapping.
2) the class enums should be numbered so that "base" classes come first
and dependent classes later.
3) If we keep the current scheme for Const$class generation and
switching, we have to use this numbering scheme:
default ... implicitely #0
odd enums ... plain class
even enums ... Const variant of class
4) Where config/* now have $pmc_names, %pmc_types is used.
5) Adding a new class starts with editing PMC.pm. If the current
numbering can not be kept, PBC_COMPAT gets an entry too and thus
invalidates existing PBCs.
6) The interactive step of selecting PMCs is IMHO unneeded. Its error
prone, rarely used PMCs can be dynamically loaded.
7) We probably have to reserve some slots for Perl5-classes
Comments welcome
leo
Some additional remarks:
1) is now autogenerated, .cvsignore and MANIFEST need adjustment too
2) e.g. ParrotIO needs NCI, PerlHash, PerlUndef already initialized
3) this would generate some empty slots in the table of vtables.
Alternatively we could use a mapping in the vtable base_type <=>
const_type. Or we always generate the Const variant of a class.
Melvin Smith
>As outlined some time ago, when ops.num made it into the core, we need fix
>assigned PMC class enums too. (Changed class enums invalidate existing PBC
>files).
>
>1) lib/Parrot/PMC.pm is the canonical source of PMC class => enum mapping.
>2) the class enums should be numbered so that "base" classes come first
>and dependent classes later.
>3) If we keep the current scheme for Const$class generation and switching,
>we have to use this numbering scheme:
> default ... implicitely #0
> odd enums ... plain class
> even enums ... Const variant of class
>4) Where config/* now have $pmc_names, %pmc_types is used.
>5) Adding a new class starts with editing PMC.pm. If the current numbering
>can not be kept, PBC_COMPAT gets an entry too and thus invalidates
>existing PBCs.
>6) The interactive step of selecting PMCs is IMHO unneeded. Its error
>prone, rarely used PMCs can be dynamically loaded.
>7) We probably have to reserve some slots for Perl5-classes
>
>Comments welcome
An additional thought. I feel there is no need to expose the enumerated
values to user-code (bytecode or native methods). Looking up PMCs isn't really
any different than looking up other symbols and could be fixed up at load time.
This does away with any ordering or numeric range reservation issues.
If I recall, Java stores class references as UTF encoded strings
of the full path to the class [java/lang/foo]
-Melvin
Jeff Clites
Yes, ObjC does something similar. At compile-time, class names in the
code become references into a per-library lookup table (stored in a
separate segment alongside the constant string segment), and that
lookup table is filled in a library-load-time with a reference to the
actual class object (or a unique int representing it). (This is roughly
the approach, at least.) So 3 attractive options here for parrot for
PMCs (and also for methods and classes) are (1) do the same thing, or
(2) at compile-time represent PMC names as strings in the bytecode, and
do a fixup run to replace these with ints (or whatever) at load time,
or (3) have an op which does the lookup by name, and which morphs
itself into an op which holds a direct reference, the first time it is
called.
To me, the 1 -> 2 -> 3 progression is very much like the evolution of
predereferencing.
JEff
Dan Sugalski
Except... if we leave the PMC numbers in the bytecode it means one
fewer level of indirection when instantiating base Parrot PMCs.
The current scheme allows for two ways to instantiate a new PMC:
1) Via a direct integer constant, which is only valid for PMCs that
were in the interpreter when it was built. (And should be usable only
for core PMCs we guarantee to be available)
2) Via an integer register. The register can be filled in by looking
up the type by name at runtime.
I'd prefer to leave the scheme as is. I'm fine with leaving a small
number of PMCs built in as "core" -- I'd be OK going so far as to say
that the *only* PMCs available this way are ones that are required
for Parrot to operate. (continuations, closures, pads, ordered
hashes, and suchlike things)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk