To wrap up (or restart) the thread, here are some thoughts from a
high-level view:
HLL classnames should live in the symbol table (i.e. namespace), not in
Parrot's internal class registry. Yes, this means PIR/POST will need
different syntax for instantiating objects from HLL classes. But the
syntax to create lexical and global variables is different than the
syntax to create Parrot's internal named temporary variables. They're
fundamentally different things, so different syntax is sensible.
The syntax for instantiating an object from an HLL class (that only
lives in a namespace) should be quick and easy.
All of Parrot's internal classes will be accessible via the 'parrot' HLL
namespace (though at times only virtually), so we don't necessarily have
to have syntax that deals directly with the registry. But there's enough
code that instantiates from type numbers to make it worth keeping that
as an option.
------
Okay, so that's what I want. Discussion: What does it break and are the
trade-offs worth it? How deeply ingrained is the Parrot class registry?
('interpreter->class_hash' is pretty thoroughly sprinkled through the
code when looking up types (curiously, the 'class_hash' is a
'enum_type_NameSpace', but a different instance of it than
'interpreter->root_namespace').)
How costly would it be to have lookups performed on the root_namespace
instead of the class_hash? If it's too costly, name-mangling the HLL
namespace name into the class_hash is a possibility, but an ugly one.
Allison
