On Wed, Mar 10, 2010 at 8:19 AM, Andrew Whitworth <[email protected]> wrote:
> 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).
I've used the term name when I meant namespace. Sorry. I'm referring
to fully qualified names here.
> 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.
That seems like a good idea, but it seems like it might be useful to
freeze complex type heirarchies in stead of creating them at load
time. Freezing a class freezes all ancestors, which is the right thing
to do. I think merging is the correct answer, but I don't think that
should be the job of the class. It seems like there might be other
cases where we want to have a unique entity for a fully qualified name
(roles maybe?). I'm not totally sure how to address this, but I
imagine some kind of NamedUniqueThingy PMC.
> 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.
Agreed. Here's a small-ish example of what I'm getting at:
> ./parrot test_1.pir | ./parrot test_2.pir
# test_1.pir
.sub 'main' :main
$P0 = newclass 'a'
$P1 = subclass $P0, 'b'
$S0 = freeze $P1
print $S0
.end
#test_2.pir
.sub 'main' :main
# uncomment this line to break b.asdf()
# $P0 = newclass 'a'
$P0 = getstdin
$S0 = $P0.'readall'()
$P0 = thaw $S0
.local pmc class_a, class_b
class_a = get_class 'a'
class_b = get_class 'b'
.const 'Sub' $P1 = 'asdf'
addmethod class_a, 'asdf', $P1
.local pmc a, b
a = new class_a
a.'asdf'()
b = new class_b
b.'asdf'()
.end
.sub 'asdf'
say 'asdf'
.end
>
> --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
