non-vtable methods on builtin pmcs
Sam Ruby
anyway: I tried adding methods to existing (builtin) PMCs. In this
case, I added a "find" method to a PyString (a near clone of PerlString).
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
Leopold Toetsch
> What I found was that I could add a regular method, but __init methods
> won't get called.
It's C<__init__> with the --python switch. But both aren't called
for plain PMCs, only for objects.
> However, any subclasses will be aware of both the
> __init and regular methods. I've attached the test I produced.
Some special vtables like C<__init>, C<__mark>, C<__destroy>,
C<__clone>, and probably more will need special treatment. They poke
around in PMC internals and shouldn't be overriden directly. It could be
useful that they first do their intended job and then call out to user
code, if present.
> 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.
That sounds great.
METHOD find(PMC* substr) {
}
> My thoughts are tha languages like Python and Ruby are going to have a
> number of such methods
Not only. We already have a bunch of such methods in e.g. ParrotIO or
ParrotInterpreter.
> - Sam Ruby
leo