On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote: > 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.
Agreed, but I think my questions equally apply to something like .HLL 'perl6'. In PGE's case, if we simply want to treat it as a library for now, in the [ 'parrot'; 'PGE'; ... ] namespace, I think we could do that for a while. But with perl6 and other languages joining parrot soon, I'm not sure it's something we should postpone for too much longer. > >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. Why is the differentiation necessary -- wouldn't "core PMCs" simply be part of the 'parrot' HLL? > 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'm afraid I wasn't able to keep up with all of the details and implications of that discussion at the hackathon. I'll be glad to chime in where I can, but I still don't understand some of the details. Thanks, Pm
