Re: Hurd OO (was Re: Unidentified subject!)

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

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> wrote:
> Daniel Burrows <Daniel_Burrows@brown.edu> writes:
> 
> > What I saw was mostly interface-implementation
> > stuff; for example, defining a filesystem interface and then having servers
> > implement it by filling in the functions.  Is inheritence also supported, as
> > in GTK+?
> 
> Some kind of inheritance is available via libdiskfs and such.
> The libraries provide default definitions of functions, and the
> program can override those if necessary; the linker sees two
> functions with the same name and chooses the one in the program.
> But this doesn't allow multiple implementations of an interface
> within one program.
> 
> In message <m11w45E-000FONC@feynman.localnet> (1999-12-09,
> Subject: Re: Perl support, concept proved), John Tobey suggested
> putting an OO layer around libports.  That would make each port
> an object with a virtual function for handling messages.  I don't
> know if he implemented that.
> 
> Stacked translators naturally use delegation instead of
> inheritance.

I haven't implemented it, and I don't have enough Hurd programming
experience to know whether it would be useful.  My impressions are:

    - The base class of all Mach objects is the `mach_port_t'.

    - A mach_port_t is neither OO nor procedurally oriented; processes
      see it as just an arbitrary small integer.

    - The Hurd server libraries like to wrap mach_port_t in a `struct
      port_info', though this is not strictly necessary.  struct
      port_info is a fairly thin wrapper with some operations defined
      in libports.

    - struct port_info can be subclassed by adding fields at the end
      of the C structure.  Furthermore, the objects carry runtime type
      information in the form of a pointer to `struct port_class'.

    - To make use of subclassed ports, code must have class-specific
      knowledge of the extra field(s).

    - Some Hurd operations act on sets of ports (`struct
      port_bucket').  The one that comes to mind is select() (but
      select() is a client-side (libc) function, so it uses a Mach
      portset, not its libports wrapper).

    - If code gets ahold of a port_bucket without knowing about the
      class of the ports contained in the bucket, it is limited to
      using libports operations on them.

    - Maybe it is never useful (outside of libports) to handle ports
      without knowing their class, in which case polymorphic
      capability is a non-issue.  The Hurd libraries seem to deal only
      with port_infos that they create and therefore know the class
      of.

    - If, on the other hand, there are uses for non-libports code that
      handles arbitrary ports in a dynamic, high-level way, it might
      be helpful to extend the meaning of struct port_info and/or
      struct port_class.  Subclassing is a way of adding operations
      ("methods") to a data type.  The ultimate subclass would accept
      a method name as a string at run time and dispatch the call,
      returning a "not supported" code if the name is unrecognized.
      In this way, objects could be self-describing.

    - If we ever want to do dynamic method dispatch with libports, we
      ought to subclass struct port_info once in a maximally flexible
      way.  I imagine a GUI might want to serve various kinds of RPCs
      from one process and allow dynamically loaded code to attach
      arbitrary data to port objects, but I may be wrong.

Hope this helps
-John

-- 
John Tobey, late nite hacker <jtobey@john-edwin-tobey.org>
\\\                                                               ///
]]]             With enough bugs, all eyes are shallow.           [[[
///                                                               \\\