Frank Heckenbach wrote:
Grant Jacobs wrote:
... snip ...
This could be confusing and/or limiting: consider this case:
unit FileOps;
interface uses FnameUnit;
function WordCount( var fname: fnames ): integer ;
implementation { expected stuff... } end.
(Leave aside the fact most people would pass the opened file, not its name!) Assume fnames is defined in FnameUnit. Naturally, we want fnames exported for users of unit FileOps. Under the 'no export' scheme the other units need to "just know" that unit FnameUnit has the definition required and import FnameUnit when using FileOps. Under the alternative scheme other units can just 'uses FileOps' and get everything they need without have to know about any dependencies. The latter has its advantages... It'd be nicer if we had the option of only passing on just the things needed by FileOps should we want to, e.g. uses FnameUnit only ( fnames ); (in analogous fashion to how import specifies subsets.)
Doing the restriction on the import would be too ... well, restricting. ;-) You might need other stuff from FnameUnit within FileOps.
So, this case would fit the proposed `export Foo = all (Bar, ...)'.
I think this shows that the original code is misdesigned. As designed, the user of Wordcount has to know about the type fnames, with no clue whatsoever about what that type actually is or where its definition is to be found. This is a maintenance nightmare.
That user has probably performed other gyrations to prepare something that he considers a member of fnames ahead of time. Thus he should already be "using FnameUnit".
Forcing the specification of fnameunit in that section of code gives a place to search.