Re: indexes
Hi, Derek,
>> Allow *any* local declarations in so included files to be
>> accessible using the standard 'dot' notation.
> Are you saying that not only global symbols, but local ones as well,
> can be accessed from outside the include file? Why is that?
First of all, Derek, this is *not* my preferred solution (see my
previous suggestion, a combination of 'global' and 'export' keywords,
'global' with the current syntax for both legacy code and important or
'system-wide' declarations, and new 'export' to be used with the dot
notation), just an alternative. I thought, you as the developer and
maintainer of a relatively large library, win32lib, would be quite
interested in the 'monolithic' concept. It would allow you to break up
the monster into more conveniently sized chunks *without* labelling
just about everything global.
> I thought the idea of having local symbols was so that the author
> can explictly hide implementation details from users of a library.
> The implmentation details being in local routines, constants and
> variables. This is pretty well agreed in computer science circles to
> be a "good thing".
To be quite honest, I do not give a damn about what 'is pretty well
agreed in computer science circles to be a "good thing"'. I have been
a scientist for more than 35 years now, and in my humble opinion,
scientists rank only very close second behind managers in promotions
of all sorts of dubious, impractical solutions to the real world
problems. But I am diverging...
There is nothing inherently good, or bad, for that matter, with
information hiding, that became suddenly so popular and important with
emergence of OO designs. In case of OO, at least, it can be almost
justified for reasons of safety.
> The idea being that the author of a library should be free to change
> the internals of a library provided that the published interface
> remains the same. If the author cannot be sure that changing an
> internal object will not break somebody else's code, it makes things
> a bit hard for everybody.
I think, the key words in the preceding paragraph are 'the published
interface'. In other words, proper documentation is really the
decisive factor. Beyond that, if as a user you rely on 'undocumented
features, you better know what you are doing ;).
>> Any 'include as' statements in an included file are, of course,
>> 'inherited' by the calling file, regardless of the level of
>> nesting.
> Why is this a good thing? I'm not sure of the "of course" aspect. I
> might be missing the impact of this.
Simplicity and consistency. Currently, I understand, only the first
inclusion of the same file is effected, all subsequent ones are simply
ignored. But you are probably right...
>> 2. flag as an error use of the same include file with a
>> different 'as name'.
>
> Why is this a good idea? I can imagine situations that would be the
> equivalent of ...
>
> include graphics.e as rds
> include graphics.e as doslib
Again, you are probably right, especially since we cannot be
absolutely sure what is included and how in shrouded files. And, as
long as differently qualified labels are just aliases referring the
same entities, it should be ok anyway.
>> 3. flag as an error duplicate use of the same 'as name' for
>> different include files.
>
> Why is this a good idea? I can imagine situations that would be the
> equivalent of ...
>
> include graphics.e as rds
> include get.e as rds
> include file.e as rds
It would not be such a good idea, if not *all* symbols of included
files were accessible from outside. But if they are, as in my second
proposal, which by the way I like much less today than I did
yesterday, then the potential for all sorts of name collisions is just
too great.
jiri
|
Not Categorized, Please Help
|
|
