Joshua Isom wrote:
I'm not sure how the imcc compiler handles the .Foo syntax internally,
but there's a file, runtime/parrot/include/pmctypes.pasm that at least
appears as though it's magically included into the beginning of every
pir/pasm file. If it were changed to output a string instead of an
integer, the dot syntax would still work with the strings(although the
under the hood part I don't know about). It's merely a macro
substitution if you think about it.
Plus it'd mean we wouldn't have to rewrite all of the tests, and keep
the old dot syntax that I personally like(easier for editors to detect a
typo).
There are several reasons to do away with constants for types and the
class registry (the type constants just supply an ID from the class
registry).
- They don't respect namespaces, so you currently can't have an
"Integer" class, for example, in multiple different HLLs. We could
mangle namespaces into the type registry, but we already have a
perfectly good way of storing classes in a namespace hierarchy, so it
doesn't make sense to implement it twice.
- They can't handle having more than one implementation of a class in
the system. This we need to safely allow dynamic changes to a class
after it has been instantiated.
And, less critical, but still annoying:
- The type constants collide with user-defined constants in
less-than-desirable ways. If you define a constant with the same name as
a type constant, the system simply ignores the redefinition and supplies
the type constant's value.
Allison
