Skip to content

Class names do not obey namespacing #1003

Open
Util opened this Issue Oct 5, 2013 · 0 comments

1 participant

@Util
Parrot Virtual Machine member
Util commented Oct 5, 2013

Reported by: zefram@fysh.org

Where classes are given a name, that name is required to be unique among classes. This is not documented. As the class's method namespace is stored in the currently-selected dynamic namespace under the class name, the impression is given that the class name is relative to the currently-selected dynamic namespace.

Actually, there's effectively a separate "class namespace", in which classes are referred to by their unqualified names. The class namespace is not directly visible, but the get_class opcode performs lookups in it. Example of clashing unqualified names that seem like they shouldn't be a problem:

$ cat t36.pir 
.namespace ["yy"]
.sub "" :init :load
       $P0 = newclass "Foo"
       say $P0
       set_global "Foo-class", $P0
.end
.namespace ["zz"]
.sub "" :init :load
       $P0 = newclass "Foo"
       say $P0
       set_global "Foo-class", $P0
.end
.namespace []
.sub main :main
       $P0 = get_global ["yy"], "Foo-class"
       say $P0
       $P1 = get_global ["zz"], "Foo-class"
       say $P1
.end
$ ./parrot t36.pir 
Foo
Class Foo already registered!

current instr.: 'parrot;zz;' pc 11 (t36.pir:9)

It's not inherently wrong to have a separate class namespace, but in this form it's seriously unhelpful, and it's totally unnecessary. The characteristics of the namespace, especially it being not directly visible, make it act quite contrary to naming in the rest of Parrot.

The regular dynamic namespace system is entirely adequate for the task of looking up classes by name, provided that one stores the class metaobjects there. (Currently classes' method namespaces are stored in the dynamic namespace, which is an abstraction inversion as discussed elsewhere. Storing the class metaobjects there instead would be more logical.) Using the regular namespace would naturally make name qualification work for class names.

If there is to be a separate class namespace, there are better ways to go about it. Firstly, it needs to be clearly documented. If the mechanism remains as it is, the documentation needs to contain a bunch of caveats about the problems with using the namespace: you can't delete or overwrite entries; everyone uses the same namespace with no name qualification, so clashes will happen a lot; it will prevent GC of a class that you don't reference any more. In fact, the documentation ought to sum this up with a prominent notice to the effect of "you probably don't want to give your classes names in this namespace". Once you've reached that conclusion, there doesn't seem to be any value in having this mechanism at all.

If you want to make the class namespace more useful, you need to add name qualification, reification, the possibility of deleting entries, and so on. In short, you need to make it just like the regular dynamic namespace. But once you've done that, there's no point keeping an identical parallel system. You might as well just use the regular namespace.

-zefram

Summary of my parrot 5.5.0 configuration:
 configdate='Sun Sep 22 18:01:32 2013 GMT'
 Platform:
   osname=linux, archname=x86_64-linux-gnu-thread-multi
   perl=/usr/bin/perl
@rurban rurban added a commit that referenced this issue Oct 6, 2014
@rurban rurban [pmc] Clarify dead coroutines
Coros are not resumable when all yield states are exhausted.
This is consistent with the LUA design, which we follow, and all other
coro implementations I know of. Just the parrot book argues that after a
return the state should be automatically reset. Technically no problem, even
without the quirks described in #564 (comment)
or via a seperate reset() method, but semantically an auto-reset is problematic.

Added testcases for all the relevant tickets: #564, #585 and there is on
bug remaining: TT #1003 leading to Null PMC access in get_string on a dead coro
27e36bf
@rurban rurban added a commit that referenced this issue Oct 13, 2014
@rurban rurban [pmc] Clarify dead coroutines
Coros are not resumable when all yield states are exhausted.
This is consistent with the LUA design, which we follow, and all other
coro implementations I know of. Just the parrot book argues that after a
return the state should be automatically reset. Technically no problem, even
without the quirks described in #564 (comment)
or via a seperate reset() method, but semantically an auto-reset is problematic.

Added testcases for all the relevant tickets: #564, #585 and there is on
bug remaining: TT #1003 leading to Null PMC access in get_string on a dead coro
60619b7
@rurban rurban added a commit that referenced this issue Oct 16, 2014
@rurban rurban [pmc] Clarify dead coroutines
Coros are not resumable when all yield states are exhausted.
This is consistent with the LUA design, which we follow, and all other
coro implementations I know of. Just the parrot book argues that after a
return the state should be automatically reset. Technically no problem, even
without the quirks described in #564 (comment)
or via a seperate reset() method, but semantically an auto-reset is problematic.

Added testcases for all the relevant tickets: #564, #585 and there is on
bug remaining: TT #1003 leading to Null PMC access in get_string on a dead coro
d14c5ed
@rurban rurban added a commit that referenced this issue Oct 16, 2014
@rurban rurban [pmc] Clarify dead coroutines
Coros are not resumable when all yield states are exhausted.
This is consistent with the LUA design, which we follow, and all other
coro implementations I know of. Just the parrot book argues that after a
return the state should be automatically reset. Technically no problem, even
without the quirks described in #564 (comment)
or via a seperate reset() method, but semantically an auto-reset is problematic.

Added testcases for all the relevant tickets: #564, #585 and there is on
bug remaining: TT #1003 leading to Null PMC access in get_string on a dead coro
6243bf6
@rurban rurban added a commit that referenced this issue Oct 16, 2014
@rurban rurban core: autoreset tests, TRACE_CORO, PARROT_TRACE_CORO_STATE_FLAG
add TRACE_CORO define, -t8 only usable when not --optimizing
fix -t2 returning from coroutine msg.
-t2 msg either Coroutine autoreset or Coroutine no autoreset
add autoreset test, not yet working (one-off same as TT #1003)
989a587
@rurban rurban added a commit that referenced this issue Oct 17, 2014
@rurban rurban [pmc] Clarify dead coroutines
Coros are not resumable when all yield states are exhausted.
This is consistent with the LUA design, which we follow, and all other
coro implementations I know of. Just the parrot book argues that after a
return the state should be automatically reset. Technically no problem, even
without the quirks described in #564 (comment)
or via a seperate reset() method, but semantically an auto-reset is problematic.

Added testcases for all the relevant tickets: #564, #585 and there is on
bug remaining: TT #1003 leading to Null PMC access in get_string on a dead coro
741b8cb
@rurban rurban added a commit that referenced this issue Oct 17, 2014
@rurban rurban core: autoreset tests, TRACE_CORO, PARROT_TRACE_CORO_STATE_FLAG
add TRACE_CORO define, -t8 only usable when not --optimizing
fix -t2 returning from coroutine msg.
-t2 msg either Coroutine autoreset or Coroutine no autoreset
add autoreset test, not yet working (one-off same as TT #1003)
f04d509
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.