On 24-Oct-1998, David Barton <[EMAIL PROTECTED]> wrote:
> Fergus Henderson writes:
>
> > 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.
>
> Let's see here --- you want him to be able to do reads like grep
> but not refer to the units directly?
The programmer should be able to read the source code;
the code that he writes, however, should not be allowed to
violate encapsulation by accessing private parts of other modules.
> You ask too much of *any* mechanism [...]
> Either you can trust the programmer to follow conventions, or you
> restrict any kind of read access; without that restriction, he or she
> can always make a local copy and do what he or she wills.
Making a local copy doesn't violate encapsulation.
One of the big advantages of language-enforced encapsulation
is that I can change the representation of private data and
I can be sure that this won't break code in other modules
or other packages. Making local copies ("cut-and-paste" reuse)
doesn't invalidate that guarantee.
> But even *if* you decide that some more sophisticated mechanism of
> version control is necessary, it is properly an operating system
> function, *not* a language function.
I need the guarantee that encapsulation provides -- the guarantee that I
can change private implementation details without breaking code in
other modules -- to hold across *all* operating systems.
Otherwise someone might be using my library on a system which doesn't
enforce the encapsulation, and my change could break their code.
> It all boils down to: access control to files is the responsibility of
> the operating system, *not* a programming language.
The entities that I want to protect are not _files_.
The entities that I want to protect are language-level entities
(functions, type definitions, etc.) so I think it is quite appropriate
for access control to these entities to be enforced by the language.
> > > 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?
>
> No; detect it and take advantage of it.
If the convention is optional, then it is much more difficult
for the compiler to take advantage of it -- detection requires
global analysis, which means for example that you can't take
advantage of the convention when doing separate compilation.
> Most of the below is variations on a theme, which make lots of sense
> if you accept the basic assumption that enforcing access control
> conventions is properly a function of the language feature; under that
> assumption, I agree with most of it.
Yep, that is our key difference of opinion.
> 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.
>
> This does not correspond to any configuration controlled project that
> I have ever worked on, so I am at sea. In my world, if you need a
> file that is outside your own package, you need to go to the
> configuration manager (who may or may not be the project manager) for
> permission to check out the file to make the change. This may be as
> simple as an Email, or it may even require review. Allowing the
> programmer to just do it, on his own hook, is well outside any kind of
> configuration control guidelines I have ever worked under.
Basically the way our system works is that you get permission
to commit the change (i.e. to check the modified file back in,
after you have already checked it out and modified it), not
permission to check out the file in the first place.
But programmers are also allowed to make changes without
getting permission, if they are confident that they changes
are going to be OK. Very occaisionally, this will mean that
permission is sometimes retracted retrospectively, by backing
out a change that has already been committed. However, this
happens only on very rare occaisions, and any disruption in
those cases is more than compensated for by the decrease in
the time lost by programmers waiting for permission.
> We work in very different environments!
Indeed.
Above I have explained in more detail above how the environment
that I work in operates. I hope that you can see how this sort
of environment could work, and that you will take my word for
it that it does seem to work pretty well for us.
> 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.
>
> And, again IMHO, it is the task of the language to *define* the
> encapsuation (or to allow that encapsulation to be defined), and the
> job of the operating system or programming environment to enforce it
> (or to trust to convention, depending).
I don't quite understand the distinctions here.
I guess there's two questions. One is whether we should
trust to convention or whether encapsulation should be enforced.
The other question is if we do want to enforce encapsulation,
whose job should it be?
Regarding the first question, I think that in general doing
a reasonable job of enforcing encapsulation is pretty easy,
and is worth doing, so we should do it. However, protecting against
people who are deliberately trying to subvert the encapsulation
is significantly more difficult, and costly, and that should only
be done if circumstances require it.
Regarding the second question, the language itself can't really enforce
encapsulation -- only language implementations could do that. The best
the language specification could do is to require implementations to
enforce encapsulation, and then we might say that the language was
enforcing encapsulation, even though the enforcement was actually being
done by the implementations.
There's not much difference between "language implementation"
and "programming environment", is there?
Above you say it is the job of the OS or programming environment
to enforce encapsulation. I think it should be the language
implementation's job, but the OS should be considered a part of
the language implementation, so letting the OS handle it would be
one way for the language implementation to do the enforcement.
--
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.
