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.)
As I started ripping things out, it seems that the current list of deprecations forces a bunch of other deprecations, which is going to involve a LOT of chopping, so, based on #parrotsketch today, I wanted to open up a dialogue regarding the basic idea here. 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.) The current tickets involve removing: - new_p_i* opcodes (gone in branch) - type* vtables - .Type constants in PIR (gone in branch) 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. Other user-facing options that expose this type ID include (I could use a double check here...) - VTABLE_morph - morph_p_i - 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 - mmdvtregister_i_i_i_p - mmdvtfind_p_i_i_i - entrytype_i_i 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? 2) What is going to replace VTABLE_type for interrogating the internal integer type? Feel free to add your own questions. Once we get some consensus about the direction we're heading in, we can continue ripping things out in the branch. Regards. -- Will "Coke" Coleda
