Re: Why doesn't this work? (short)
On Sat, 17 May 2003 12:56:49 -0400, Robert Craig
<rds at RapidEuphoria.com> wrote:
>Whenever a file is included, the global symbols in that file
>become visible in the including file, and all the code
>that comes later (in other files). This might not have been
>the best way to do things (maybe the globals should become
>invisible at the end of the including file), but it has
>been that way since day 1, with few complaints. If it were
>changed now, it would break a lot of code, and require
>people to add a lot of extra include statements.
Unless I am seriously missing something about the examples posted,
this is about namespaces, and the ability of namespace qualifiers to
<my word no one elses:> unambiguously determine the intended reference
The question is, without a namespace qualifier, is it unambiguous when
two versions of a global exist (albeit one included with a qualifier
and one not). I argue no, because the interpreter cannot know whether
it is an old line or a mistyped new line.
In an ideal world, i'd like to see global constants and routines with
///the same binary signature/// not raise any eyebrows, so to speak,
whenever there is a potential ambiguity. But that's a side issue.
Otherwise I'm quite happy (so far) with the way globals currently work
I am kicking and screaming and stamping my feet because I fear
something might be put in to automatically resolve an ambiguity, in a
way the programmer cannot override, and/or in a way that will be very
difficult to spot. Hopefully I'm paranoid 
Pete
PS Have you considered my claim that conflicts within an include
could actually be unambiguously resolved?
|
Not Categorized, Please Help
|
|
