#1492: Get_class <namespace> confuses NSes that have same final name.
-----------------------------+----------------------------------------------
Reporter: Austin_Hastings | Owner: whiteknight
Type: bug | Status: new
Priority: normal | Milestone:
Component: core | Version: 2.1.0
Severity: high | Keywords: namespace, class, get_class
Lang: | Patch:
Platform: |
-----------------------------+----------------------------------------------
Comment(by whiteknight):
After looking through this some more, I can't think of a good way to fix
this as-is. Here's the situation:
When we call get_class<namespace> and the requested class does not
currently exist, one of two things could plausibly happen: (1) we return
PMCNULL, or (2) we create the necessary class object on the fly and return
that.
Confusing this issue is the fact that we don't always get back a Class,
sometimes for built-in types we would get a PMCProxy instead. In case (1)
above the get_class opcode would only need minimal changes but calling
newclass is obviously wrong unless we make newclass smart enough to detect
a built-in type name and create the PMCProxy instead of Class. In case (2)
above, get_class would need to detect the built-in type name and then
create the PMCProxy or Class object appropriately.
Since the arguments we're talking about here are NameSpaces, it's not a
simple matter of calling NameSpace's get_string VTABLE to get the class
name, since each namespace only contains the "last name". We would need to
walk the entire ->parent chain to assemble the "full name" of the
namespace, and then use that to determine if the type is built-in or not.
No current functions in Parrot are suitable for this operation, and I
suspect it will be difficult because C-based dynpmcs could be loaded into
a different HLL namespace.
Also we need to consider what to do in the case of an HLL override,
whether we would want get_class to return the class of the override
instead of the built-in type (this is a design decision that I think we
can delay making for now).
This ticket becomes much easier to resolve if PMCProxies for C-based PMCs
are created more eagerly at VM startup time, or dynpmc load time. In that
case, the NameSpace's get_class VTABLE ''always returns a non-null
PMCProxy'' for C-based types, and the behavior of get_class<namespace> op
becomes substantially easier. In case (2) above, get_class<namespace>
either returns the existing proxy, returns an existing class, or creates a
new Class (not needing to ever worry about creating a PMCProxy or
conflicting with an existing C-based PMC type name). In case (1) above,
newclass would need to lookup the NameSpace and ensure the ->class slot
isn't already filled with a PMCProxy or existing Class, and then create a
new one. Of course, if we're being passed a NameSpace as an argument, the
lookup is already done.
I think chromatic's current plan for #389 is to create PMCProxies eagerly
as I describe here. If that's the case, we can fix this ticket shortly
thereafter. If this is not his current intention or the final result of
that work, I don't think this ticket can be reasonably fixed.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/1492#comment:3>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
