Dan,
I think there is a real problem with your vtable approach. It involves
tying, overloading and assignment. I'm not sure if I really got what you
meant with the PDD, but I'm assuming:
1. PMC's replace SV*.
2. Tying is handled by vtables that implement set_* and get_* entries to do
the magic stuff.
3. Overloading is handled by vtables that implement add/subtract/mul/...
entries to do the magic stuff.
4. There's only one vtable for each class of variables, i.e. all variables
tied to class X share the same vtable, and all objects that have overloading
defined by class Y share the same vtable (this seems obvious, since it's the
vtables that define the behaviour in case of tying/overloading).
5. On a $a = $b assignment, the PMC correspondent to $a after the assignment
is the same it corresponded before it. I.e. $a is set to the value of $b by
calling set_* methods of $a passing some information of $b or $b itself as
parameters, and not replaced with a new generated PMC derived from $b
somehow.
The problem I see concerns assignment, like $a = $b. What will be the vtable
of $a?
Suppose $b is tied. The vtable of $a should not be the one of $b, since by
this assignment $a doesn't get tied, it only fetches the value of $b. That
means the vtable of $a should probably be one of the `plain' vtables of
perl, to handle simple datatypes (of course it could be a special one, but
it doesn't matter here).
Now suppose $b is overloaded. For instance, let's say $b is a bigint, with
overloaded +,-,*,... to do the right thing in the case it's operated with
other values. Then, by $a = $b, $a receives the bigint stored in $b, and
should inherit (bad word) or copy $b's behaviour of add/subtract/mul/... .
As I suppose a new vtable wouldn't be created (as this would cause one
vtable per variable on multiple following assignments), I presume the vtable
of $b would have to be copied to $a.
But now we get into a contradiction: if $b is tied, the vtable should not be
copied; but if $b is overloaded, it should be copied. Now what should happen
if $b is both tied and overloaded? That's not impossible, since $b can, for
example, be tied to a random number generator and be programmed to return
bigints of 512 bits (that's actually only to say it's thinkable to have tie
and overload together, I'm not expecting someone would do something like
this...).
Other awkward consequences would happen if $a is tied and $b is overloaded.
$a = $b would make $a have to use $b's add/subtract/mul/..., but using $b's
vtable in its entirety would untie $a, right?
That's actually what made me feel the need for a separation between
store/fetch and add/subtract/mul/... . I've been tried to figure it out how
your proposal would fit this situation, but I couldn't find a way...
I actually don't know if my assumptions are wrong, and tying and overloading
would not be handled by set_*/get_* and add/subtract/mul/..., but I actually
can't see another way.
What do you think about it?
- Branden
