At 08:04 PM 8/2/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > TheObj *foo;
> > SV *new_sv;
> > foo = new TheObj("A parameter");
> > sv = perl_new_sv();
> > perl_make_sv_object(sv, "Some::Package", foo, &dispatch_routine,
> > &destroy_routine);
> >
> > perl_return(perl_make_ref(sv));
>
>Are you really thinking about keeping "SV *" and two-level refs
>and all that? That sounds an awful lot like the current internals.
SV * as it exists in perl 5? No. Some magic cookie that perl's internals
passes to extension code? Yep, you bet. Probably should've used PMC instead
of SV * to distinguish them.
As for returning refs rather than real objects, well, I'm not sure that we
want to do that, but some sort of decoupling of the object guts and a
handle to the object is a terribly useful thing. It means that objects live
out past their creation scope without having to do odd things. It also
means that:
my $foo = new Thingie;
my $bar = $foo;
still give you a single object rather than two. Perhaps some sort of object
aliasing would be possible, so rather than getting references, the sv_any
equivalent of all the different object copies all pointed to the same
object structure.
>I'd like to see *minimal* overhead for simple scalars -- if we
>could cram immediates (like small integers and booleans) directly
>into the "SV *" that seems like a big win.
Sure. That'll all be hidden behind the variable vtable, and behind a layer
of stable wrappers for extension code.
>For foreign objects, I'm not sure why you're forcing a two level
>dispatch. Why not let the foreign code register dispatches directly
>in the scalar's vtbl?
Simplicity. I want this code to be dead simple, something a mildly retarded
chimpanzee could use.
There is absolutely nothing stopping us from defining a more complex
interface *in addition* to this one--people can register op-style functions
that get stuffed into a package's symbol table and call into object code
directly if they like. But this is a ground-floor level interface, one that
should take your average non-perl extension writer (like, say, the person
tasked with embedding a perl interpreter into the C++ framework library, or
who wants to weld perl into Emacs or Freeciv) can get things going with a
minimum amount of fuss and bother.
Your extended way's cool too--RFC it and we can do that as well.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
