At 1:23 PM +0100 5/23/02, Peter Haworth wrote:
>On Tue, 21 May 2002 12:18:50 -0400, Dan Sugalski wrote:
>> At 8:44 AM -0500 5/20/02, brian wheeler wrote:
>> >I've been trying to catch up with parrot again (darn it, babies take more
>> >time than I thought :) and I've come up with a question... how do you do
>> >"other" things to PMCs that aren't normal ops?
>>
>> Call methods on the perl-level classes that map to the PMCs.
>
>What if the functionality required isn't available through any number
>of vtable method calls? Is this what user/language defined ops are for,
>or do even more vtable methods have to be defined? If the latter, where
>do we stop?
The former. If the languages have needs that aren't implemented as
vtable functions, they'll need to implement them as class methods.
It's acceptable for the methods of a class to peek at the internals
of instances of that class, so that's not a problem. (Though there
are the general issues of subclassing here, of course)
> > >In particular, I was wondering about shift/unshift, push/pop on the
>> >PerlArray PMC. Am I missing something obvious?
>>
>> Ah, those. In that case you use the vtable methods I've forgotten. :)
>
>Will these all map to a splice vtable method, or will there be a
>method for each?
At the moment, I'm thinking of vtable entries for splice, shift,
unshift, push, and pop. The point of the vtables is to allow
specialized code to take shortcuts, so the more we have, up to a
point, the better.
How these map to actions for scalars is up in the air. I can see
splice being the equivalent of substr, and pop the equivalent of
chop, for example, but that's probably a bad way to go.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
