Simple directories don't need processes to hold them. They can be implemented as nodes holding a key to a node containing keys and a key to a page containing their names and traversed by library routines. As long as you can do anything with a start key you can do with a page or node key, the library can be fairly oblivious to directories implemented in other ways.
This is probably a bad idea for extensibility.
Rob is, of course, correct about thinnings: while you only inherit a method from one superclass (or super-interface), you may have several thinnings that allow it.
I'm not sure that downcasting in Java is a design flaw; in particular, it makes possible the implementation of generic and heterogeneous container classes, such as the directories being discussed. If you have two chunks of code exchanging Walnuts through a Vector, they should be allowed to get the Walnuts as Walnuts, rather than having to treat them as Objects and invoke polymorphic Object methods overridden by Walnuts in order to get Walnut behavior out of them.
(Of course, if the Vector can just remember that they are Walnuts, you have solved the problem. You can do this in Haskell, at least for built-in containers, and you can do it in C++ with templates, but not in Java.)
Likewise, I might like to have some set of EROS programs that expect that the ".." entry of a Dionysix directory process is a Dionysix directory.
The L4 HotOS 97 paper "Achieved IPC Performance" claims <1uS IPCs on Pentium-166s. Is this bogus? If not, why is EROS fast-path IPC pipe latency an order of magnitude slower at 18uS? (I know it involves several IPCs, but ten?)
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Perilous to all of us are the devices of an art deeper than we ourselves
possess.
-- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]