Thanks for the direction here, very helpful. On Wed, Apr 2, 2008 at 3:28 AM, Allison Randal <[EMAIL PROTECTED]> wrote: > For a bit of background: the goal is to someday eliminate type IDs entirely > from Parrot. They're fundamentally broken, because they assume a static > class set in a flat namespace. They assume that the type ID assigned to a > class will be identical when you freeze and thaw bytecode, which isn't true > between different runs of the same Parrot install (because different dynamic > PMCs or PIR classes may be loaded), and isn't true between different > installs of Parrot (because different compiles of Parrot may have different > core PMC sets, and also different dynamic PMCs or PIR classes loaded). > > But, some deeply rooted core features depend on type IDs, notably: > > - low-level object creation (pmc_new, pmc_new_init, etc) uses type IDs. > - multiple dispatch uses type IDs > - vtable lookup uses type IDs > > So, the compromise is to remove the user interface to type IDs now, so that > by the time we remove the last traces of type IDs from the system, the users > won't even remember they exist. The PDD says "We may eventually be able to > eliminate the registry of class IDs altogether." > > > Will Coleda wrote: > > > There are several tickets open regarding the integer type ids that > > have been open for some time, and with the type_ids branch, we're > > getting close to actually removing this long-deprecated feature. (I'd > > like to just rip out *everything* we need in this branch, rather than > > continue doing it piecemeal in trunk.) > > > > Excellent idea! > > > > > The tickets have been open for some time, and I think the original > > intent has gotten lost: based on what allison has said today, the goal > > is to remove the -user visible- usage of these integer type IDs, but > > we're still allowed to use them inside parrot internals. (which may > > involve resurrection something in src/ that got deleted early on in > > the branch.) > > > > Don't resurrect anything. If it's been ripped out and everything still > works, that's wonderful. Progress toward the ultimate goal. > > > > > The current tickets involve removing: > > - new_p_i* opcodes (gone in branch) > > > > +1 > > > > - type* vtables > > > > I'm not sure what you mean by this.
These four VTABLE entries are deprecated. INTVAL type() INTVAL type_keyed(PMC* key) INTVAL type_keyed_int(INTVAL key) INTVAL type_keyed_str(STRING* key) > > > - .Type constants in PIR (gone in branch) > > > > +1 > > > > > There is a lot of usage of VTABLE_type in the code base, however, so > > removing these vtable entries means we need another way to get at this > > information: MMD, for example, uses the integer type IDs to handle > > dispatch. > > > > The MMD implementation milestone is coming up right after concurrency, and > type IDs for dispatch are on the chopping block. > > > > > Other user-facing options that expose this type ID include (I could > > use a double check here...) > > > > - VTABLE_morph > > - morph_p_i > > > > Change to take a PMC class (or class proxy), or a string class name, or key > namespace name, the same as we changed 'new'. Eliminate the integer > versions. > > > > > - new_p_i_s #must have missed this one when I ripped out the other new's. > > - typeof_i_p* > > - findtype_i_* > > - valid_type_i_i > > > > Rip them out if possible. > > > > > - mmdvtregister_i_i_i_p > > - mmdvtfind_p_i_i_i > > > > Hold for the MMD implementation milestone. > > > > - entrytype_i_i > > > > This is checking for PMC/STRING/INTVAL/FLOATVAL of an entry on the user > stack, not class ID, so is fine. > > > > > So, my questions: > > 1) Can we rip out what's in this list of still to do? Is there > > anything that we need to provide a new variant for, like the mmd > > opcodes? > > > > General principle: eliminate type IDs everywhere you can. Where they can't > be eliminated yet (for example, where removing them needs a rework of a > major subsystem), make a note of the dependency, so we can come back and rip > it out once the dependency is removed. > > > > > 2) What is going to replace VTABLE_type for interrogating the internal > > integer type? > > > > VTABLE_type will stay as long as we need to interrogate the internal > integer type, and be removed as soon as we can remove it. > > Allison > > -- Will "Coke" Coleda
