Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
According to pdd21, each HLL gets its own hll_namespace.
PGE is really a form of HLL compiler, so it should have
its own hll_namespace, instead of using parrot's hll namespace:
.HLL 'pge', ''
I don't know that that's necessarily the case, but it's definitely an
option. You can just as easily argue that it's a library.
Now then, the 'PGE::' prefixes on the classnames were
just implementation artifacts of working in a globally
flat namespace -- as a high-level language PGE really
ought to be referring to its classes as 'Match',
'Exp', 'Literal', etc. So, if we're in the PGE HLL,
we ought to be able to drop the 'PGE::' prefix from
our classnames and namespaces.
So, here's the revised version of the code to create
the classes:
.HLL 'pge', ''
.sub __onload :load
$P0 = newclass 'Exp'
$P0 = subclass 'Exp', 'Literal'
$P0 = subclass 'Exp', 'Group'
$P0 = subclass 'Exp', 'CGroup'
$P0 = subclass 'Exp', 'Subrule'
$P0 = subclass 'Exp', 'Closure'
# ...
.end
This code fails when run from parrot, because Parrot seemingly
already has a class named 'Closure':
$ ./parrot ns.pir
Class Closure already registered!
current instr.: '__onload' pc 19 ( ns.pir:9)
$
So, this brings me to my question: What is the official
"best practice" pattern for HLLs to create their own classes
such that we avoid naming conflicts with existing classes
in Parrot and other HLLs?
This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
a relic of the past and I think it needs to change. I'm pretty sure
that HLL classes will have to go into the HLL's root namespace (this
needs to happen anyway to prevent namespace pollution). That leaves us
with the question of how to differentiate core PMCs from HLL PMCs. I'm
not sure how to handle that, but that's what a spec is for.
We discussed some of this briefly at the OSCON hackathon, when we
talked about changing the class internals so that a Class isa
Namespace. That discussion hasn't led to any changes yet as Chip has
been kidnapped by his Real Life (tm).
I think the object model needs a thorough going over in general -- for
the reasons above and because it's an unproven system. I'm not
convinced that it will handle all of Perl 6's needs as is. No serious
OO language has been implemented yet on Parrot; everything up to this
point has been either procedural or functional.
--
Matt Diephouse
http://matt.diephouse.com
