From: Edwin Steiner [mailto:[EMAIL PROTECTED]]
>
> Branden wrote:
> >
> > and the other thing is that creating a
> > vtable for another type would break all existing types.
> >
> > Example: suppose we want compiled regexes (qr/^xyz$/)
> > to have its own vtable so that we could inspect them
> > and the regex-engine would interact with them by a clear
> > interface. If we don't make it at first, adding them later
> > would probably break scalars, arrays, hashes, and so on.
>
> I get your point. But considering what Dan said about *not
> exporting vtables* I wonder how many data types will
> directly rely on vtable layout. I would think all data
> types implemented outside the core will use an additional
> level of indirection (tie-like callbacks?). So maybe there
> will only be a hand full of 'very internal' data types
> depending on the vtables.
I thought one of the benefits of vtables was to facilitate extending support
for new types?
Does RFC 32 have any place in this discussion?
Per RFC 32: A method of allowing foreign objects in perl
>
> Since writing half a zillion perl2WhoKnowsWhat modules is
> going to be unweildy, not to mention different for each and
> every object type, perl punts. We require that the code we
> interface to defines a dispatch function for each object,
> and we then just call the dispatch function with enough
> information for it to Do The Right Thing.
>
> From the perl programmer's point of view, foreign objects
> and native objects look the same. Perl will define some
> generic conversion routines (to int, float, and string)
> which the foreign code is welcome to override if it wishes.
And in a possibly related thread which appears to predate the mailing list
archives:
John Tobey writes (Thu 08/03/00 10:47):
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > > Feel free to define some recommended functions. Give
> > > > 'em all upper-case names so they don't get confused
> > > > with real methods. (I hope) A PERL_ prefix might not
> > > > be a bad thing either.
> > >
> > > The only one I feel strongly about here is TYPENAME,
> > > which should, perhaps, be called by Perl's ref()
> > > builtin. Hey-- then as a first try, method calls
> > > could do a Perl fetchmeth()! Wouldn't that spiff!
> >
> > Yep. :) Make it one of the vtable entries--that way you
> > can get a generic perl magic cookie pointer and find out
> > what the heck the thing really is.
>
> Making it a data member of the vtable sacrifices extensibility. I
> started doing Perlmacs that way until I realized this.
