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

Re: PDD 2, vtables

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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About