[perl #40438] [BUG] Extending a dynpmc with a PIR method fails
Will Coleda via RT
parrotbug-followup at parrotcode.org
Wed Feb 25 16:45:45 UTC 2009
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
> 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?
> this ticket is to be kept open could someone please change the
> 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"
> .sub main :main
> $P0 = newclass 'PerlString'
> $P0 = get_class 'PerlString'
> $P0 = subclass $P0, 'NewPerlString'
> $P0 = new 'NewPerlString'
Will "Coke" Coleda
More information about the parrot-dev