RE: Namespace improvement ?
Juergen Luethje wrote:
<SNIP>
> The approach with a new keyword such as 'shared' might be even more
> flexible than the 'local/global include' idea:
> The author of a file that will be included in one or more other files
> can decide *for each symbol individually* whether it is local, 'shared'
> or global.
>
> One might say that an additional scope such as 'shared' can be confusing
> for newbies. Maybe, I don't know.
>
> You know that I always supported the 'local/global include' idea in the
> past. But to be honest, we have to face the fact that this also can be
> confusing for newbies:
> Say someone defines a global procedure foo() in a file A, which then is
> 'locally included' in file B. File B is included in file C. Now s/he
> writes foo() in file C, expecting that this will call the procedure in
> file A. We know that this will not work, but a newbie might think:
> I declared procedure foo() as global, so why *isn't* it global?!?
>
> That means a symbol declared as global will only be "really global", if
> the file in which it is defined is "globally included". So some symbols
> will be only "relative global", while others will be "really global".
> ( Or maybe "local global" and "global global" -- SCNR 
)
> *That* is confusing, isn't it?
>
> The more I think about it, the more it seems to me that, when a new
> scope is created, a new keyword for this scope should be used -- for
> the sake of clarity.
>
> Another difference:
> Using 'local/global include', the author of the includ*ing* file(s)
> determines the scope. Using my 'shared' idea, the author of the
> includ*ed* file(s) determines the scope.
> I don't know what is better / more flexible or whatever.
>
> I just wanted to throw the idea with a new keyword for a new scope into
> the discussion, leaving it to the experts to judge about it. But it was
> not meant as a compromise.
>
> Regards,
> Juergen
>
> --
> I didn't have time to write a short letter,
> so I wrote a long one instead.
> [Mark Twain]
>
The problem with 'shared', is that you are simply extending the existing
functionality, instead of rectifying the situation.
People would still be able to make everything global, (and they will)
'shared' would supplement the problem, so if used correctly, they would
be able to produce well insulated code, but the actual problem of
reducing the global pollution is not really addressed.
Also, there is already lots of code in the archives that is casuing
problems already, by the use of global. Using shared would mean that
they have to go back through all of their code, and figure out which
'global's they want to make 'shared' instead. That's alot of work that I
don't think many people will do. So what we end up with is the same
problem, with an optional solution.
That is why I considered it to be a comprimise.
Global include demands that the user specify how they intend for the
library to be used, which IMO is the correct behaviour. I don't care
what the authors intentions were, if I find a good use for a bit of
code, I would like to be able to use it without having to resort to
customizing the lib.
One of my philosophies for programming is that a good program/api never
has to be edited, or even looked at by 3rd parties. If proper
documentation is available, I should never have to look at other peoples
confusing code, and have to figure it out.
Chris Bensler
Code is Alchemy
|
Not Categorized, Please Help
|
|
