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.
- .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
