Dan Sugalski wrote:
> 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)
One C++ problem I just found out is memory management. It seems
that it's impossible to 'new' an object from an specified memory block.
So it's impossible to put free'd objects in memory pool and re-allocate
them next time.
>
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
--
Sincerely,
Ye, Wei
