Weird type/identifier conflicts

Peter N Lewis peter at
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:

unit WonderSound;


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 mailing list