At 3:08 PM +1300 2/3/03, Grant Jacobs wrote:
At 7:25 PM +0100 1/3/03, Frank Heckenbach wrote:
Grant Jacobs wrote:
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.
Sigh. I'm not sure if you're getting it. Whether not or not you use inheritance or make the higher level directly import dependencies (i.e. without inheritance), this same issue is present in both cases. Its not something that distinguishes the models. The uses at the lower level in inheritance and the uses at the higher level without inheritance faces the same issue of what to import (and in the case of inheritance, what to re-export). The difference is that the opportunity to have intermediate level units present what is needed for use of their unit is lost, so that without inheritance the higher levels are forced to maintain the dependencies of lower level units. Does that help?
Perhaps this would be a useful thought experiment. Say I wrote a unit "WonderSound" to handle all sorts of Sound stuff, and it became wildly popular and was used by lots of folks, and so I decide to update it and add lots more functionality, and so I break the unit up in to more manageably parts, like WonderSoundInput and WonderSoundOutput and WonderSoundFilters and WonderSoundFiles etc. With Uses Propagation, I can include a unit like:
unit WonderSound;
interface
uses WonderSoundInput, WonderSoundOutput, WonderSoundFilters, WonderSoundFiles;
end.
and then all existing code works unmodified and future users can choose either to use only the unit they need, or just use WonderSound and get all the stuff.
For this to be useful, the units have to ensure they have non-conflicting names, as is generally easy to do if it is all an interface on to one conceptual library.
Please note I'm not advocating Uses Propagation as something that has to go in to GPC, just trying to clarify where it might be useful. There is certainly a good case to be made against uses propagation, and I think I'd rather see some sort of extension to allow this to be used where appropriate, perhaps something like a synonym for "uses" that also reexports the listed units, or perhaps something like "uses WonderSoundInput (reexport);" or perhaps in the style of "external", something like "uses WonderSoundInput; reexport;" although that would really require allowing multiple "uses" statements to allow for some that were reexported and some that were not. Just some ideas, it would require more thought to know what if anything was the best way of including this facility.
Enjoy, Peter.