[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
1. Packages should be used for coarse-grain control of
name conflicts, not fine-grain control. In other words, I think
it's necessary to put the compiler, the window system, and
the mail system in separate packages, but I don't think we
should force a naive user writing a small program to spread
his identifiers among several packages simply because we
didn't give him proper scoping mechanisms for objects.
The naive user ought not to have to worry about the implementation.
He ought merely to be able to state that an identifier should be
protected. An implementation with packages is sufficient
(and can be easily understood by the user if needed).
2. An analogy. Suppose function BAR modifies a global
variable N. Function FOO, which calls BAR, innocently
binds a local N. Should this break BAR? Of course not;
that's what lexical scoping is for. No one would advocate
putting FOO's N and BAR's N in separate packages in this
case; lexical scoping is a much more elegant solution.
It is the case that one requires of a user that one declares a
variable N global, or at least special (or declares implicitly
or explicitly that FOO's N is local). The same is true for the
solution described above. One shouldn't confuse user view
3. Users should be AUTOMATICALLY protected from
inadvertent name conflicts so they don't get screwed in
the ways I warned about in my proposal.
Our experience is that users know much more than you imply,
and usually are using name coincidence purposefully. Implementors
who use obvious names for "hidden variables" which are left
unprotected are at fault. They should use a "private"
declaration which could be implemented with a package
name. Warnings on definitions that further specify named
variables are an easy add on. One could distinguish the case in
which the user put the name conflict in the ":include option"
where they were clearly aware of it, and those which occur in
----- End Forwarded Messages -----