Simon Cozens wrote:
> On Tue, Feb 06, 2001 at 11:30:12AM -0200, Branden wrote:
> > I actually have some more on it, but I'm saving it for the next
postings.
> > I'll wait for your opinions first. I really hope to see critics about
this.
>
> I don't understand what you think this gives us that the PDD doesn't.
To explain the difference, I'll show how the Perl statement
$foo{bar} = $baz + $xyzzy[42];
would be traduced in both approaches.
In the approach using the vtables I propose, it would be:
// get the PMC's that correspond to each variable...
HVAR *foo = get_hvar("foo");
SVAR *baz = get_svar("baz");
AVAR *xyz = get_avar("xyzzy");
// temporary...
SVAL *foo_val = new_sval_temp();
SVAL *baz_val = new_sval_temp();
SVAL *xyz_val = new_sval_temp();
// this ones actually come from compiler...
SVAL *foo_key = new_sval_pv("bar");
SVAL *xyz_idx = new_sval_iv(42);
// fetch $bar and $xyzzy[42] values
baz->vtable->FETCH(baz_val, baz);
xyz->vtable->FETCH(xyz_val, xyz, xyz_idx);
// add them into a temporary
baz_val->vtable->ADD(foo_val, baz_val, xyz_val);
// probably xyz_val->vtable->INTEGER(xyz_val)
// and/or xyz_val->vtable->NUMBER(xyz_val) would
// get called by the ADD implementation, to
// inspect the right operand's value.
// store this value on $foo{bar}
foo->vtable->STORE(foo, foo_key, foo_val);
Using the vtable approach proposed in the PDD:
// get the PMC's that correspond to each variable...
PMC *foo = hv_get("foo");
PMC *baz = sv_get("baz");
PMC *xyz = av_get("xyzzy");
struct key keys[] = {
{ KEY_TYPE_HASH, (struct hash_key *) "bar" },
{ KEY_NONE, NULL }, // scalar
{ KEY_TYPE_ARRAY, (IV) 42 },
{ 0, 0 } };
foo->vtable->add(foo, baz, xyz, keys);
Right? (Maybe I got it wrong, but for what I've read, that's it...).
Well, when %foo, $baz and @xyzzy are plain hashes, scalars and arrays, it's
ok. But now suppose %foo is a hash tied to a database through DB_File or
AnyDBM, @xyzzy is attached to a directory so that $xyzzy[42] would actually
return the name of the 43rd file in that directory, and the string stored in
the $baz variable has overloaded + so that it will check if the other
argument is a string or a number, and concatenate in case it's a string and
sum only if both are numbers. How would foo->vtable->add(foo, baz, xyz,
keys) deal with that? As it is %foo's vtable, I agree that it should know
about %foo being tied to a DBM, but how would it know anything about the
others?
In the approach I'm proposing, xyz->vtable->FETCH(xyz_val, xyz, xyz_idx)
would ask for the element indexed 42 of the array. As the vtable used is the
one of the array itself, it knows it should fetch it from the directory
listing, and does it. In baz_val->vtable->ADD(foo_val, baz_val, xyz_val),
the ADD method is called from the $baz vtable, so it knows about $baz being
overloaded. (Of course overloading this way only applies to the left
operand, I don't know if there's a workaround for this). The ADD method gets
the right operand by calling STRING/INT/NUMBER on the last argument. And
foo->vtable->STORE(foo, foo_key, foo_val) is responsible for storing the
value on %foo, using foo_key as the key. STORE is in %foo's vtable, so it
knows it should actually write the data in the DBM.
I really can't see how this would be implemented in the PDD proposed
approach, unless foo->vtable->add(foo, baz, xyz, keys) makes the calls in
the other vtables. And if it makes all these calls in the other vtables, I
don't see the point, because every `add' function would have to explicitly
do 2 fetches and 1 store, yet taking care of the keys, when it could
actually only do the addition...
Perhaps I didn't understood it quite well, but that's what I thought about
it...
>
> --
> For me, UNIX is a way of being. -Armando P. Stettner
>
For me too.
- Branden
