On Dec 1, 2003, at 9:01 PM, Melvin Smith wrote:

At 10:40 AM 11/28/2003 +0100, Leopold Toetsch wrote:
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]

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


Reply via email to