Re: Perl support, concept proved

[John Tobey <jtobey@john-edwin-tobey.org>]

>   Hmm.  I've been meaning to do some translator stuff over break if I get a
> chance.  So you know what this means, of course?  Simple: I'm going to have to
> write Python bindings >=)

LOL!  :-)

It occurs to me that a process running multiple interpreters (Perl,
Python, Java, e.g.) would like to be able to share Hurd port
structures among languages.  From what I've been able to make of the
Ports Library interface, this would be difficult without (a) rewriting
an object-oriented version of libports or (b) putting an
object-oriented wrapper around libports.

By object-oriented I mean supporting dynamic binding with something
like a virtual table.  Hurd's `struct port_info' objects are
associated with a `struct port_class'.  They are allowed to add fields
to the structure and use the pointer polymorphically; for example,
trivfs.h defines a port "subclass" for representing user ids (I think)
like this:

  struct trivfs_protid
  {
    struct port_info pi;
    struct iouser *user;
    int isroot;
    /* REALNODE will be null if this protid wasn't fully created (currently
       only in the case where trivfs_protid_create_hook returns an error).  */
    mach_port_t realnode;		/* restricted permissions */
    void *hook;			/* for user use */
    struct trivfs_peropen *po;
  };

Because it is associated with a port_class (I believe) the trivfs
library will not pass a trivfs_protid pointer to a function registered
for some other port class.  Thus, ports from different classes can not
be intermixed freely.

If my intuition is right, perhaps basing our bindings on a common
wrapper would be good in the long run.

-John