At 03:23 PM 9/29/00 -0400, ye, wei wrote:
>Dan Sugalski wrote:
>
> > At 02:29 PM 9/29/00 +0100, David Mitchell wrote:
> > >Regarding the tentative list of vtable functions:
> > >I'm rather worried about binary operators, eg 'is_equal', 'add' etc.
> > >The danger with these is that they may impose a single implementation
> > >of scalars upon us.
> > >
> > >As an example, suppose I wrote an alternative scalar implementation that
> > >was optimised for many small string appends followed by a single get
> > >of the wholpe string at the end. (I might internally do this with a linked
> > >list of blocks, say; then allocate a single large block at the end to
> > >return the whole string.)
> > >
> > >If sv1 is a standard SV and sv2 is an append-optimised one, then
> > >
> > >(sv1->vtable[IS_EQUAL])(sv1,sv2) would crash and burn, because
> > >sv1's 'is_equal' function doent know that sv2 has a different internal
> > >representation.
> >
> > Your worries are well-founded, but ultimately not a problem. (I do like
> > those kinds... :)
> >
> > Since the generic internal representation of a variable is hidden from
> > anything but that variable's vtable, the scenario you propose can't happen.
> > What'd happen instead for a plain ASCII string compare would look something
> > like:
> >
> > bool is_equal(pmc1, pmc2) {
> > if (strcmp(pmc1->string, to_string(ASCII, pmc2)) {
> > return Perl_FALSE;
> > } else {
> > return Perl_TRUE;
> > }
> > }
> >
> > Overloading does present an ordering issue, and one I am worried about. It
> > either requires all the vtable functions to know about all the variable
> > types (which is impossible, unfortunately) or it means perl needs to
> > dynamically reorder the operation so the 'bigger' variable's function gets
> > called.
> >
> > Reordering's also not a 100% panacea--it's fine for ops involving a base
> > type and an extended type, but it can potentially break down with two
> > extended types. (What happens when you add a complex number with a complex
> > bigint, if the two types have no idea about each other?)
>
>I have been wondering why not write Perl in C++ from ground? Performance?
>Portability?
Availability is a big one--we can certainly guarantee any of perl's current
platforms has a C compiler, but we can't assume a C++ compiler. Also
there's not a whole lot that C++ would buy us, and writing C++ code to be
usable from C (or other non-OO languages) is a big pain in the neck.
>In C, it takes alot of time to design vtable ,however still couldn't work
>completely as OO.
That's fine--we don't want it to, really.
>If write in C++, the vtable will be generated during the compile phrase and
>perfectly.
"Perfectly" is an awfully dangerous word to use around computers... The
compile-time vtable stuff doesn't do us much good, since we may well be
building it up at runtime, amongst other things. We'd also need direct
access to it to mess with, which is a big pain. (And Chip's already
experienced the joy of trying this with C++. He didn't much like it)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
