|
Re: non-vtable methods on builtin pmcs: msg#00295lang.perl.perl6.internals
Sam Ruby <rubys@xxxxxxxxxxxxxxxx> wrote: > 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 |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: parrotcode.org: release 0.1.1?: 00295, William Coleda |
|---|---|
| Next by Date: | Re: [perl #31726] [TODO] non-branching compare opcodes - JIT: 00295, Leopold Toetsch |
| Previous by Thread: | non-vtable methods on builtin pmcsi: 00295, Sam Ruby |
| Next by Thread: | [perl #31962] [PATCH] synchronous NCI callbacks: 00295, via RT |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |