On 1 Mar 2003 at 12:48, Grant Jacobs wrote:
[...]
When uses is placed into an interface, all of the interface of used unit is propagated (inherited, etc.) unless the programmer restricts what is imported in the uses.
No.
[This is what I was hoping for, that is.]
That wouldn't comply with the UCSD/BP "standards" for units.
And as I said, I thought this was how MW Pascal units did things. Anyone know how Delphi/Kylix goes about this? (My 'Deplhi in a Nutshell' isn't helpful here and I haven't time to test this just yet.)
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. I certainly do not want to automatically reexport all interfaces to all units that I might be using. This can, IMHO, lead to nothing but confusion.
This would have the disadvantage that separate compilation (automake) wouldn't be possible ...
I know! -- I'm getting frustrated enough that I might just have to do this... (I don't *want* to...) Modern computers are fast enough speed won't be an issue, but re-use of the units eventually will. I'm just trying to get the initial port going at all first!
What is wrong with simply using all the units that you need in any source wherein you need them? Am I missing something here?
[...]
Importing <> declaring. The things are declared in the interface section of the lower-level units, but not in the one of the present unit.
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!)
No, most people would not. In fact, not a single Pascal programmer would. How did you come by this idea?
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.
Yes. It is up to the programmer to supply that information. Supplying it takes only two seconds: "Uses FNameUnit;". If one does not want to edit every source file manually, supplying "--uses=FNameUnit" on the command line should to the job. I am not sure what the problem is here.
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.)
It seems that what you want is a hybrid of units+modules+something_else The rules for units and modules are quite clear (according to the standards being supported thereby). Something_else would be a new thing, with its own rules. I am not sure where that will lead us! I personally would not have thought that "interface inheritance" was a desirable thing to add (nor would I have thought that it was a priority at this point in time). The problems you raise are easily addressed by "--uses". Why do we need something else?
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.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/