On Tue, Sep 06, 2005 at 10:49:32AM -0400, Matt Diephouse wrote: : That's what I'll eventually be getting to. But in order to design : those methods well, we need to know what tasks we need to accomplish. : What's even more important, I think, is the storage slots for the : necessary information. Where should ParTcl store the original : namespace for all of its commands, for instance? Probably somewhere in : the namespace PMC, but it ought to be a thought out place.
Yes, we've just come to the conclusion over in p6l-land that a package object *isn't* just a hash. It *contains* a namespace hash as one of its attributes. In fact, it probably contains at least two hashes, one for public symbols, and one for private, which makes it really easy to make the first set of symbols visible, and the second set not, without going through filtering contortions. So Parrot needs to not confuse namespace PMCs with hashes. Namespaces need to be ordinary objects with ordinary accessor lookup to get at their contents. Baking in hashes as the one true representation of symbol tables would just repeat the same fundamental mistake as P5 OO. Symbol tables need to be more opaque than that. At least for Perl 6 we need to be able to derive from packages to produce modules and classes, and that means we should't make any assumptions about how packages store their data. I realize Parrot is working at a different OO level here, but I suspect the principle still carries over, and it would be nice if there weren't a large impedance mismatch between Parrot's namespaces and Perl's. Going through accessors goes a long way to solving the interoperability problem, since an accessor can do fancy things like a fallback search through sigil space when called from languages that don't support sigils. And namespace lookups don't generally have to be that fast, to the extent that you can factor them out to compile time. Larry
