Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:39 PM 8/2/00 -0400, John Tobey wrote:
> > > A scalar is made an object via a call into the perl library. The
> > > scalar is marked as an object and stuck into a package. Attached to
> > > the scalar is a pointer to the native object, a pointer to a generic
> > > dispatch routine, and a pointer to the native destruction routine for
> > > the object.
> >
> >Perhaps add a native mark routine, if we are really GC-agnostic.
>
> When the object finally goes out of scope then we call the destroy method
> and assume that everything hanging off the object pointer is gone. That
> only leaves the perl bits to clean up, and we know about those.
Don't assume that the Perl interpreter is the sole root of
accessibility. Maybe some other language has 'us' (i.e., the
interpreter) as an object and needs to mark all its own objects that
we refer to for the benefit of its own GC.
> >Native serializer? Equality tester? Type id accessor? What prompts
> >me to propose these is the struct that evolved in Perlmacs for mixing
> >Perl and ELisp objects:
>
> 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!
-John
> On the other hand, we may have a serialize (or equality) function as part
> of the sv vtable, in which case the point's moot, sort of.
>
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
>
>
