[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