[perl #40438] [BUG] Extending a dynpmc with a PIR method fails
Ron Schmidt via RT
parrotbug-followup at parrotcode.org
Sat Feb 21 01:28:22 UTC 2009
On Thu Mar 22 08:57:04 2007, mdiep wrote:
> As leo noted above, this an issue with HLLs and namespaces.
> Specifically, all classes are
> defined in the 'parrot' HLL namespace, not the actual HLL namespace.
>
> This code works:
> .sub main :main
> getclass $P2, 'PerlString'
...
> .end
getclass is no longer an operator and has been replaced by get_class
which is not quite used as above. The updated sample below seems to
work OK and I am wondering whether there is really still a problem
with "classes ... defined in the 'parrot' HLL namespace, not the actual
HLL namespace." and if there is still a problem here at all. If there
is, could someone please explain a bit further what the problem is? If
this ticket is to be kept open could someone please change the ticket's
subject to reflect the existing namespace issue?
I am also guessing that since this turns out to have been a namespace
problem rather than a dynpmc the tests should be moved from their
current location in t/dynpmc/subclass_with_pir_method.t to either
t/pmc/namespace.t or something like t/pmc/subclass_with_pir_method.t.
The tests may also have to be altered to reflect current usage of
accessing a method in subclass when the method is in a namespace
belonging to an HLL namespace.
Updated example that seems to work:
.HLL 'Perl'
.namespace ['PerlString']
.sub 'perl_printhi' :method
print "HI from PerlString\n"
.end
.sub main :main
$P0 = newclass 'PerlString'
$P0 = get_class 'PerlString'
$P0 = subclass $P0, 'NewPerlString'
$P0 = new 'NewPerlString'
$P0.'perl_printhi'()
.end
More information about the parrot-dev
mailing list