What I found was that I could add a regular method, but __init methods won't get called. However, any subclasses will be aware of both the __init and regular methods. I've attached the test I produced.
I'm not overly concerned about __init methods, in fact, my concern is the opposite: I'd like to solicit opinions on the viability of extending pmc2c2.pl to enable non-vtable methods to be defined, in C, in the .pmc file itself.
My thoughts are tha languages like Python and Ruby are going to have a number of such methods (as well as a few attributes) defined in many of the predefined classses. Any such methods are likely to be frequently enough used that optimizing for such cases is warranted.
- Sam Ruby
#! perl -w # Copyright: 2001-2003 The Perl Foundation. All Rights Reserved. # $Id$
=head1 NAME t/pmc/buildin-meths.t - Builtin Methods =head1 SYNOPSIS % perl -Ilib t/pmc/builtin-meths.t =head1 DESCRIPTION Tests the ability to add methods to builtin PMCs. =cut use Parrot::Test tests => 2; use Test::More; output_is(<<'CODE', <<'OUTPUT', "PyString::find"); ##PIR## .sub main @MAIN $P1 = new PyString $P1 = "short string" $P2 = new PyString $P2 = "string" $P3 = $P1.find($P2) print $P3 print "\n" .end .namespace [ "PyString" ] .sub __init print "In PyString::__init\n" .end .sub find method .param pmc argument $S1 = self $S2 = argument index $I1, $S1, $S2 $P1 = new PyInt $P1 = $I1 .pcc_begin_return .return $P1 .pcc_end_return .end CODE In PyString::__init 6 OUTPUT output_is(<<'CODE', <<'OUTPUT', "SubString::find"); ##PIR## .sub main @MAIN getclass $P1, "PyString" subclass $P2, $P1, "SubString" find_type $I0, "SubString" new $P3, $I0 $P3 = "longer string" $P4 = new PyString $P4 = "string" $P5 = $P3.find($P4) print $P5 print "\n" .end .namespace [ "PyString" ] .sub __init print "In PyString::__init\n" .end .sub find method .param pmc argument $S1 = self $S2 = argument index $I1, $S1, $S2 $P1 = new PyInt $P1 = $I1 .pcc_begin_return .return $P1 .pcc_end_return .end CODE In PyString::__init 7 OUTPUT