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
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
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