Grant Jacobs wrote:
At 10:10 AM -0800 28/2/03, Russell Whitaker wrote:
On Fri, 28 Feb 2003, CBFalconer wrote:
Grant Jacobs wrote:
.. snip ...
Since these uses statements were within the interface section, I presumed the definitions would propagate upwards so that they form a hierarchy. Or, put another way, I assumed the interface of a unit is extended by any units it uses in its interface section.
That would be very poor practice, since it would expose routines, types, variables in areas where one wishes to keep them inaccessible. Uses does not, and should not, mean export.
Not quite. given:
Unit foo; interface uses bar; implementation uses nobar; begin end.
In any user of foo, anything in the interface section of bar should be visable; unit nobar remains hidden.
Thanks, this is exactly what I meant. I need to do a little testing: it may be that --automake not "drilling down" the units or some other silly thing is confusing me. I'll get back once I'm done.
Note that its not the uses that does the export (I never meant to suggest or imply that!), but the interface. Uses only does an import. If the uses is placed in the interface, the interface of that unit gets inherited/propagated/call-it-what-you-will.
Let's try a little analogy:
PROCEDURE foo;
PROCEDURE bar;
PROCEDURE baz; BEGIN END; (* baz *)
BEGIN END; (* bar *)
BEGIN (* baz is totally invisible here *) END; (* foo *)
(* If the earlier bar were visibile, we couldn't *) PROCEDURE bar; BEGIN END;
BEGIN (* baz is invisible here *) (* bar is locally defined, nothing to do with foo *) END.
Now think about the name conflicts that can arise if everything is visible everywhere. Consider foo ensconced in a separate module, which in turn uses a module holding bar.
The point is to enable break up into separate compilations without causing inexplicable errors.