[perl #40438] [BUG] Extending a dynpmc with a PIR method fails

[Will Coleda via RT]

On Fri Feb 20 17:28:19 2009, ronaldxs wrote:
> 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?

In your example here, you're not using dynpmcs - you're using a PIR 
class as the base; The original sample code is old enough that it 
referred to the PerlString dynpmc which is no longer in core.

> 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


-- 
Will "Coke" Coleda