{ copied to P6L for the "use case" question below }
On Wed, May 17, 2006 at 12:18:27PM -0400, Will Coleda wrote:
> My concern is that, in an effort to work around this restriction,
> each language will end up implementing a workaround to hide the
> __parrot* namespaces: these workarounds will hinder interoperability
> unless they are synchronized: if they're synchronized, why not
> canonicalize them and put it in the core?
That's a good argument, and I take it seriously.
My initial answer is that you're aiming for a goal I don't think is worth
trying for. I simply don't expect the Parrot-hosted versions of HLLs to be
100% indistinguishable from their other versions from a user experience
point of view, in the same sense that various C compilers or Unix variants
are distinguishable to users, despite their efforts at common support.
Since a 100% invisible Parrot is not achievable, we can start considering
the practical consequences of any given visibility. I don't imagine that
more than a tiny fraction of _user_ code would be at all inconvenienced by
the appearance of /^__parrot/ names in their namespaces. (Or /^\0P\0/ e.g.)
OTOH, as you observe, HLL authors may well need to account for it, and two
parallel HLL hacks generally imply the need for a standard Parrot hack.
> That said, I'm still trying to figure out why a class's methods have
> to be stored in a namespace ...
Well, that arrangement isn't necessary per se. In fact, we already have a
real-world exception -- methods of the "namespace" class are not stored in a
namespace, for chicken-and-egg reasons. That said, there are still some
egg-and-chicken issues with defining methods without using a namespace.
(See below.)
> Matt Diephouse suggests that it's because methods are subs, and subs live
> in a namespace, but is there a use case (HLL requirement) for doing
> _namespace_ lookup for finding a method in a class?
The user for which the use case exists is no HLL, but Parrot itself:
Classes can be created at runtime ("newclass"), while method definitions (as
all subs) are acquired at pbc load time. When Parrot loads the methods for
a class, that class per se may not even exist yet! In the gap, mehtods must
be stored _somewhere_, and right now, namespaces serve that purpose.
Thus, removing the ".namespace ['classname'] ... .sub methodname" idiom for
runtime-created classes requires the invention of some new idiom, and it is
that invention that the "__parrot_class" proposal dodges.
OTOH, I could just invent the PIR syntax and let Leo figure out how to
implement it. Hey, it worked for the ISO C++ committee. :-/
--
Chip Salzenberg <[EMAIL PROTECTED]>
