[un-CC'ed to librarian - is this correct procedure?]
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> =head1 TITLE
>
> A method of allowing foreign objects in perl
I like it.
> =head1 VERSION
>
> Maintainer: Dan Sugalski <[EMAIL PROTECTED]>
> Date: August 02, 2000
> Version: 1
> Mailing List: perl6-internals
> Number: XXX
>
> =head1 ABSTRACT
>
> Currently it's a darned pain to deal with objects created in other
> languages in perl. It would be very nice to be able to call a function
> written in some other language, take the returned object, and treat it
> as a perl object. (Which means making method calls and such on it)
>
> =head1 DESCRIPTION
>
> Everybody and their dog has written an object-oriented language at
> this point, and it'd be nice to be able to use objects created by
> those languages as if they were real perl objects. This would make
> interfacing perl and OO languages[1] easier, and make things much
> nicer for embedded and embedding code.
>
> 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.
>
> =head1 IMPLEMENTATION
>
> 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.
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:
struct Lisp_Foreign_Object_VTable
{
Lisp_Object (*type_of) P_ ((Lisp_Object self));
void (*destroy) P_ ((Lisp_Object self));
void (*mark) P_ ((Lisp_Object self));
Lisp_Object (*to_string) P_ ((Lisp_Object self));
int (*equal) P_ ((Lisp_Object self, Lisp_Object other, int depth));
Lisp_Object (*call) P_ ((Lisp_Object self, int nargs, Lisp_Object *args));
};
-John
> Native code would create the object thusly:
>
> 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));
>
> When you make a method call in perl, like so:
>
> $native_obj->foo($bar, $baz);
>
> perl calls the underlying dispatch routine to do the actual work. The
> dispatch routine has a function signature like so:
>
> int status = dispatch(void *native_obj, sv *perl_scalar, char *method_called,
> int *num_args_in, perl_arg_stack *arg_stack,
> int *num_args_out, perl_arg_stack *return_values);
>
>
>
> =head1 REFERENCES
>
> None I can think of
>
> =head1 FOOTNOTES
>
> [1] Like, say, C++ or Scheme
>
>
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
