Re: PDD 2, vtables

Front page | perl.perl6.internals | Postings from February 2001

Thread Previous | Thread Next

From:

Dan Sugalski

Date:

February 7, 2001 10:31

Subject:

Re: PDD 2, vtables

Message ID:

5.0.2.1.0.20010207132624.01ad6e48@24.8.96.48

At 04:15 PM 2/7/2001 -0200, Branden wrote:
>David Mitchell wrote:
> >
> > Well, many of the vtable methods are operator-ish rather than value-ish,
> > presumably on the grounds of efficiency. A pure 'value' vtable wouldnt
> > have add(), concatenate() etc. Whihc leads me back to: I'm not sure
> > whether you are in favour of, or oppose, += etc being vtable methods.
> >
>
>Oppose. (Actually I'm talking about my idea on vtables, i.e. separate +/-/*
>in one vtable and store/fetch in another). My proposal on ++ and -- would be
>having the `value'-part of the vtable (the one that handles +/-/*) return a
>value corresponding to what would be the value of it after an increment or
>decrement. store would be used to actually commit the ++/-- operation. This
>would serve both postfix and prefix cases, because in one case the value
>before the store would be used, and in the other the one after.

Splitting the vtable into two pieces, with one piece not tied to a PMC, 
makes some things impossible. Consider this:

   @foo = @bar * @baz;

where all three arrays are really matrix types. In the separate load/store 
and do vtable scheme it means you get the value of @bar and @baz in scalar 
context, and multiply the results. Two operations, and the resultant values 
are sanitzed. In the single vtable scheme, we'd execute @bar's multiply 
routine, which would be clever enough (because we wrote it that way) to see 
the second parameter's also a matrix, and do matrix math.

Splitting things up also loses information when moving data between the two 
vtables routines. While that's not a big deal generally (as the info lost 
is irrelevant) it forbids some rather interesting side cases.

>(I just reminded the C++ overloading of ++, that uses a dummy parameter to
>tell if it's a pre or a post increment. So bad...)

I'm not sure it's worth having both a preinc and postinc operator, as 
opposed to splitting it into an inc/fetch or fetch/inc pair. (And yes, I 
know, earlier I was arguing that one opcode's better than two. This one's 
rare enough that profiling it would probably be in order...)

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

Thread Previous | Thread Next