|
Regarding the name space inclusion: Your callback to Ruud nicely confirms my empirical findings. Thank you.
Concerning my non-usage of INCLUDE: Let me explain.
I have to maintain 74 loginscripts. They reflect 74 departments of my company, each one has a unique dedicated loginscript. Don't ask about the irritating number of departments or the dedication of separate scripts - it is the way it is. Politics, OK ?
As a way of dealing with this ancillary conditions, I did the following: Each script just contains a set of CALLs to script modules delivering specific functionality (let us assume a [definitly too] simple example: mapping a network share). I have 43 modules yet (12000+ effective code lines), most of them generic ones which can be parameterized by INI-files, but this is a different story ...
When changes to departmental loginscripts are requested, lets say they want a functionality to be added, I just pick one of those modules and make a CALL to it. Sometimes I have to implement a new module for this but most of the time I have a fitting one ready for a CALL. Done. Or I just remove a CALL for the opposite case (they don't want a specific funtionality any more for their department). Done.
For general changes to a specific functionality (let us assume for the above example: change in the network share mapping logic) I edit the corresponding module. Done.
For this whole scenario the new pretokenization feature just requires a pretokenization run for the changed departmental/sub-script file. Done.
Straightforward, simple, maintainable for other guys when I'm at vacation ... this an absolute must, take my word for it.
Now consider what happens if I change this to using INCLUDE instead. A change of a departmental script just requires retokenization of this specific script. Easy.
A change in a CALLed (sorry: INLUDEd) script requires retokenization of any departmental script which references that sub-script. This is a call for headaches. To make this stuff work automatically I would have to build some makefile dependency tree for departmental/sub-script references and have to use this for automated rebuilds of relevant files. But even with this automatism there is trouble ahead: adding/removing CALLs (read: INCLUDEs) without changing the makefile accordingly will lead to disaster. This is an additional administrative task for script maintenance that will predictably fail sometime, by all means when I'm on vacation. Again, take my word for it. I am definitly not fond of being called in my holidays because of mysteriously failing loginscripts. This kind of trouble is what I want to avoid desperately. Therefore I need to keep the script environment complexity at a foolproof level.
Did this explanation helped in understandig why I prefer CALLs instead of INCLUDEs ?
OldFart
| 
