[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: <heh@xxxxxxxxxx>
- Subject: RE>file friends
- From: Mark S. Miller <vlad!mark>
- Date: Sat, 6 Oct 90 22:48:57 PDT
- Cc: <xanadu!ravi@xxxxxxxxxxx>, <xtech@xxxxxxxxxx>
- In-reply-to: 47 <9010051728.AA14355@xanadu>
Date: 5 Oct 90 10:15:47
From: heh <xanadu!xanadu.com!heh>
Now that I think about it, this is an extension of an idea that I first heard
markm propose, which is modularity at directory levels. For example, having a
public interface file for "spaces" which just defines the general interface for
coordinate spaces (like spacex.hxx now). By directly using integerx.hxx, you
are essentially declaring yourself a "friend" of the spaces module and are
using the submodule integer.
Well, I'd say go ahead and add the module friend feature (to include the
p.hxx) and we should revisit the module visibility question in the near future
(say, 2 months after 1st Dev release).
All this friendship stuff sounds good. But please let's remember to
revisit it as Heh suggests. A more interesting parallel with class
modularity which would be interesting to explore is the notion of a
protected header--one intended for inclusion not by clients but by
those who want to implement a service defined by this module. For
example, "integer" would include the equivalent of
"space-protected.hxx" instead of being a friend.
Would all the cases where people are encountering problems with our
current visibility mechanisms be solved by introducing "protected"
headers? If so, should we do that instead?