Grant Jacobs wrote:
At 5:43 PM -0500 28/2/03, CBFalconer wrote:
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.
Firstly, you're "cheating" in that you're using nested procedures and I'm sure you realise units and modules aren't designed to be tied to procedures and functions so this e.g. is purely academic from my point of view.
I'd say the analogy is just as (in)valid as yours with classes. ;-)
Units/modules are tied to other units/modules, not to procedures or functions, at least in the implementations I know of!
Not in those I know. They can refer to each other, but they're not tied to each other. (Might be nitpicking, but I think that's just the question at hand.)
Secondly, I never meant to imply everything is visible everywhere nor that it ought to be. Obviously, what you expose depends on the application at hand. On the note of hiding/exposing, a little philosophy FYI (at the risk teaching grandmother suck eggs, so to speak):
If a unit doesn't want something to be visible to code that imports the unit, the programmer simply doesn't place that thing in the interface section of the unit. Done.
Nope. If, say, one type from the sub-unit is needed for an interface declaration, the sub-unit must be used in the interface. This generally doesn't mean that everything from it should be re-exported.
The importing units can choose to import all, some or none of the things offered up for import by any unit it uses, assuming there is a mechanism to selectively import items (obviously importing nothing of something you use doesn't make sense, but it *is* conceptually an option!).
This places more control in the hands of the code using units.
While this is true (and possible with GPC), it's not exactly in line with your original argumentation. You complained that you have to list several units (instead of one) in the `uses' clause, now you suggest a way where you have to list many identifiers from each unit, i.e. an order of magnitude more.
In the procedure-based code, higher levels have no option but to accept what is defined at lower levels.
I think that's true *with* automatic re-exporting, not otherwise.
What you seem to want is for units/modules to be able to choose to dictate what units/modules can use them
Not at all (unless you take his analogy a little to far).
(this is in effect what nesting does). We could come up with a construct like 'export bar only to foothingies, specialthingies;'. [This isn't a suggestion, Frank!! :-)]
I hope not -- I surely wouldn't do that. ;-)
The only way to make your example work under current schemes (as I understand them) is to move the inner bar outside foo; [...]
You really seem to have misunderstood his analogy. He wasn't trying to implement nested routines as units or vice versa, just saying that the behaviour is (in some regard) similar.
Peter N Lewis wrote:
In the Mac world, this is generally called "Uses Propagation" and was always on in THINK Pascal and is a compiler switch in CodeWarrior.
The best use of it is for writing a unit MacOS.p that includes all the MacOS API interface files for you in one go, rather than have to specify them each explicitly as you use them. Is there any way to get an equivalent to this in GPC?
Not directly.
For your own units in a normal program, it's probably not particularly useful.
Well, if it's only for the interfaces, I wouldn't suggest amending the compiler for that (same as I think about the asmnames).
If the interface units are generally all used together, anyway, it would be easy to put all their contents into one unit (can be done automatically with a simple script).
Prof A Olowofoyeku (The African Chief) wrote:
A unit exports only things in it's own interface section. If you use another unit, it only allows you access to things in the interface section of that other unit - and that is all it does. Any program/unit that desire similar access has to use the other unit for itself. This behaviour is far safer IMHO to the "interface inheritance" that you propose. Like Frank, I think that interface inheritance will cause problems.
Well, I don't think that it will cause problems per se, but it might lead to confusion, especially if it's on by default. Implementing it would probably not be too hard, but I've yet to be convinced that it's really useful ...
It might of course be easy to add this type of inheritance if the unit mechanism were object oriented, but I don't know anything about the internal implementation of it.
It's not related.
Frank