Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

__set_pmc_keyed(_int|_str)? on custom classes

0 views
Skip to first unread message

Patrick R. Michaud

unread,
Oct 10, 2005, 8:21:01 PM10/10/05
to perl6-i...@perl.org

Is it possible to use __set_pmc_keyed(_int|_str)? to
detect when a PMC object is being subscripted with an
integer versus a string argument?

In particular, I'd like to be able to detect the difference between
the keys used in the keyed assignments below:

$P0 = new "MyClass"
$I0 = 5
$S0 = 'foo'

$P0[$I0] = $P0 # called with an integer key
$P0[$S0] = $P0 # called with a string key

I've tried defining "__set_pmc_keyed_int" and "__set_pmc_keyed_str"
but they seem to have no effect; Parrot seems to always want to
call "__set_pmc_keyed" regardless of what is placed in the brackets.

I've also tried variations of @MULTI, and they just seem to
result in segmentation faults:

.sub __set_pmc_keyed method, @MULTI(int, pmc)
.param int key
.param pmc val
...
.end

.sub __set_pmc_keyed method, @MULTI(string, pmc)
.param string key
.param pmc val
...
.end

Any clues, help, or pointers? And of course I have similar
questions for the __get_pmc_keyed.* methods. :-)

Thanks in advance,

Pm

Leopold Toetsch

unread,
Oct 11, 2005, 7:34:36 AM10/11/05
to Patrick R. Michaud, perl6-i...@perl.org
Patrick R. Michaud wrote:
>
> Is it possible to use __set_pmc_keyed(_int|_str)? to
> detect when a PMC object is being subscripted with an
> integer versus a string argument?

It wasn't until r9445. The problem was that classes/default.pmc has
fallback methods that create PMC keys. Unfortunately we sometimes need
these default methods in custom classes too, but in this case it's
clearly wrong.

I've now special-cased the *_keyed_int methods, to first look for a user
function and then use the fallback in default.pmc, if no user method exists.

Please note that this works only for the *keyed_int methods. The
*keyed_str methods are not accessible from the opcode level, these
always call the 'pmc' _keyed variant (w/o suffix). See also the added
test in t/pmc/object_meths.t

> I've also tried variations of @MULTI

Multis work only for real sub objects and would need some support inside
classes/delegate.pmc (where the actual method dispatch is located). But
as plain vtable methods aren't NCI objects, but plain C functions, we
could have a mixture of PMCs and C functions, which would be a mess.

OTOH infix MMD functions are created as NCI objects and can be used with
MMD.

> Thanks in advance,
>
> Pm

leo

Patrick R. Michaud

unread,
Oct 11, 2005, 8:32:34 AM10/11/05
to Leopold Toetsch, perl6-i...@perl.org
On Tue, Oct 11, 2005 at 01:34:36PM +0200, Leopold Toetsch wrote:
> It wasn't until r9445.
>
> I've now special-cased the *_keyed_int methods, to first look for a user
> function and then use the fallback in default.pmc, if no user method exists.

Excellent, works exactly as I need it to now.

> Please note that this works only for the *keyed_int methods. The
> *keyed_str methods are not accessible from the opcode level, these
> always call the 'pmc' _keyed variant (w/o suffix).

That's fine -- as long as I have some mechanism to distinguish "int"
from "everything else" then it's very sufficient for my purposes.

Thanks again!

Pm

0 new messages