[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: <ravi@xxxxxxxxxxx>
- Subject: RE>file friends
- From: heh <heh@xxxxxxxxxx>
- Date: 5 Oct 90 10:15:47
- Cc: <xtech@xxxxxxxxxx>
Reply to: RE>file friends
>I've run into a couple of situtations where I need access to a private
>class outside the file in which it is defined. For example, I want to
>make subclass in another file (which is also private to its file). In
>C++, I could do this by including the p.hxx file, but there is
>currently no mechanism to do this in smalltalk. Does anyone have any
>objections if I add a "friends" aspect to files in the browser,
>listing the files that are allowed to see its private header, and
>change the include scanner appropriately?
Well, I have also run into the same situation (in mine, with regard to a test
class that needs to access the private class directly to test it correctly).
I think the idea of "friendly modules" is a good one, although we should
minimize it's use. It does solve a number of problems.
I think it would be best if the browser implementation would allow an easy
addition of something like a "show friends" function, which would list all the
modules which declare the current one to be a friend (and thereby be scarfing
off with the p.hxx).
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).