Namespaces *should* be able to have the same names so long as they have different parents, so Foo::Bar::Baz should be a different namespace than Bar::Baz (See TT #1492 for a bug that really prevents this behavior).
Multiple classes should be able to have the same short name so long as they correspond to different namespaces. On first blush, I suggest it should be an error to load in a namespace with the same fully-qualified name as an existing namespace. A little more flexibly, Maybe there should be an option to merge namespaces with the same names (in the case of a class that is defined across multiple files), and maybe an option to append all loaded namespaces into a specified parent namespace. Most libraries and compilers should be defining their own top-level "HLL" namespace to avoid collision anyway. In any case, loading a namespace and causing a collision should be an error, and I think silently thawing classes into anonymous classes is the wrong solution. --Andrew Whitworth On Tue, Mar 9, 2010 at 11:06 PM, Peter Lobsinger <[email protected]> wrote: > Hi, > > Working on tt1015 I've run into some snags. > > Is the namespace of a class a property of the class? I'm pretty sure > it is, but it leads to questions I don't know how to answer. > > Can there be more than one class that has the same namespace even if > looking up a class using this namespace returns only one, or possibly > none, of these? > > If classes have their namespaces and are unique per namespace, if I > clone a class, I should get the exact same class back, right? If I > clone, I want an object that has all the same properties, but there's > only one class tobject that can have this namespace. > > If classes have their namespaces and aren't unique, I should get back > a copy with the same namespace, correct? > > We have a test that says clones should be anonymous, but this doesn't > quite make sense to me from either perspective. The only way I can see > this making sense is if classes don't have their names, but I'm pretty > sure that's not the case. > > In the current system, if you freeze a class and thaw it in a new > parrot that has not loaded this class, it will install itself in its > namespace. If there's already a class loaded in that namespace, it > won't. But if the class is not loaded but its parent is, the parent > will be anonymous (and separate from the already loaded class), but > the child will be installed in its namespace. This could be confusing, > for example, when monkey patching. > > I just can't see how that is right. Either classes are unique > per-name, in which case the child should reference the official > version of the parent class, or classes aren't unique, in which case, > it should be perfectly normal to have a class not be in its namespace > and classes shouldn't be put into their namespaces automatically on > thaw. > > BTW, the tt1015 branch is based on the assumption that clone(x) = > thaw(freeze(x)). If this shouldn't be true, I would very much > appreciate an explanation as to why. > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
