Re: Hurd OO (was Re: Unidentified subject!)
Kalle Olavi Niemitalo <firstname.lastname@example.org> 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
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
- 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
- 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 Tobey, late nite hacker <email@example.com>
]]] With enough bugs, all eyes are shallow. [[[