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
