Weird type/identifier conflicts
Peter N Lewis
peter at stairways.com.au
Sun Mar 2 15:42:27 CET 2003
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
>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:
uses WonderSoundInput, WonderSoundOutput, WonderSoundFilters, WonderSoundFiles;
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.
More information about the Gpc