On 22-Oct-1998, David Barton <[EMAIL PROTECTED]> wrote:
> Fergus Henderson writes:
> > I would tend to disagree, because if privacy is enforced by the
> > language, then (1) the programmer can be sure that it will be
> > respected and (2) the compiler can use the information to
> > perform optimizations such as specialization and dead code
> > elimination that otherwise might not be possible.
>
> 1) If the programmer is himself alone, then he can be sure he respects
> it himself; if the programmer is someone else, then different uids
> should work just fine.
No, different uids don't work fine in the multiprogrammer case.
The programmer that is compiling the source code needs read access
to all of it (for using tools like `grep', if nothing else).
Once he has that read access, nothing prevents him from violating
the encapsulation.
> 2) The compiler can (and should) be intelligent enough to detect the
> importation of symbols only through non-functional (gather)
> modules. This is not a big test to perform.
So the compiler should enforce this convention?
OK, that's a major improvement. Now it's not just a convention
anymore. Now you do have something that can stop people from
violating encapsulation.
If you do this, then the "gather" modules are now special enough
that I think they might even deserve special syntax, e.g.
calling them `interfaces' rather than `modules'.
But now the system is getting a bit more complicated ;-)
Also there are some cases where the convention could be a little tedious.
In the case of a package which contains only a single module,
it seems a bit silly to require an extra gather module
that just imports and re-exports all the symbols exported
from the original module.
If you have nested modules, then you can still program in the
"gather" module style if you want to. It would look something like this:
-- package `p' has two interfaces, which
-- are specified in the gather modules g1 and g2;
-- the implementation of package `p' is in modules m1, m2, and m3.
-- I'm using Haskell style syntax + "is seperate" for (sub-)modules
-- defined in different files
module p(g1, g2) where {
module g1 is seperate
module g2 is seperate
module m1 is seperate
module m2 is seperate
module m3 is seperate
}
But with nested modules you also have the option of just exporting the
submodules directly rather than going via gather modules.
> > This should properly be left to the programming environment. On
> > a Unix system, it could be implemented by granting group and
> > world read privileges only to the public gather modules.
>
> That doesn't work unless you use different uids when compiling
> different modules, which would be impossible in many situations
> and ridiculously inconvenient in almost all situations.
>
> Not different modules; different packages, which is quite a different
> thing. Nor is it all that difficult to do; chgrp as part of the make
> file works just fine.
Well, I haven't tried that kind of system, but my gut feeling is
that there would be a lot of problems. We get enough problems
with permissions already, without trying to do anything fancy!
On most Unix systems, only `root' can create a new group.
Any scheme that requires root privileges to create a
new package is going to be a complete pain in the neck.
> RCS and CVS (at least the versions I have used) are very happy to
> provide read access only to selected modules that are checked in to
> the system.
I don't see how that helps. Every programmer on the team may need
to modify any file (in order to fix a bug, for example).
So all programmers need write access to every file.
> I can see (to an extent)
> your "using uids doesn't work" argument in a standard Unix file
> system; I can't really see it in RCS or CVS, where you have to check
> out the operational (as opposed to gather) modules in order to gain
> access to them.
Well, normally I check out all the modules in the system.
With CVS, I type out `cvs checkout mercury' and it checks out all the
modules in the entire system, giving me both read and write access to
all of them. Then I type `make' and it compiles everything.
This is nice and simple, and it works.
If you want me to change to some other kind of configuration management
system, or to use CVS in a significantly different way, then I would
need a fair bit of convincing ;-).
> This may come down to the area of a base disagreement: "I think this
> is better and you think the opposite." I have certainly worked in
> environments such as that I describe and have had no problems with it,
> but that may be a matter of what you are used to.
Yes, you may be right. But I don't think a language should require
the use of a particular configuration management style. And therefore
I'm not keen on any solution which relies on the configuration management
style rather than the language to enforce encapsulation.
Cheers,
Fergus.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
