1. Re: Namespace improvement ?
Chris Bensler wrote:
> Chris Bensler wrote:
>>
>> Juergen Luethje wrote:
>>>
>>> Me wrote:
>>>
>>> <snip>
>>>
>>>>> Chris Bensler wrote:
>>>>
>>>> <snip>
>>>>
>>>>>> Realistically, it would break most everybody's code.
>>>>>> However, the transition would be very minor (change all cases of
>>>>>> "include foo" to "global include foo").
>>>>
>>>> Yes, very minor. And this replacement can be done automatically by a
>>>> small program.
>>>
>>> <big snip>
>>>
>>> Another idea with the same effect, that does not break a single line of
>>> existing code ...
>>> ( I don't remember whether or not this has also been discussed before.)
>>>
>>> Let the syntax of the 'include' statement alone, and introduce a new
>>> keyword, say 'shared', that can be used, whereever 'global' can be used:
>>> shared sequence foo
>>> shared function foo()
>>> etc.
>>>
>>> The only difference to 'global' would be, that the 'shared' symbols are
>>> only shared between the file where they are defined, and the file that
>>> *directly* includes this file.
>>>
>>
>> I strongly oppose any solution geared to compromise, when a better
>> solution is available.
>>
>> Fix the scope of includes properly, and be done with it. We don't need
>> to introduce any new concepts, just ammend the current concept of
>> includes.
>>
>
> I will elaborate a little bit on my perspective regarding this.
>
> Take C for example, or better yet, C++.
> They are both good languages, but they have been severely 'compromised'
> for the sake of satisfying immediate demands and for the concern of not
> inconveniencing the current user-base.
>
> If backward compatability really is that big of a concern (and I don't
> think it is one bit), there are methods that can be taken to introduce
> new functionality, and ween out the old, called deprication. Large
> software projects almost inevitably have to deal with legacy behaviour
> at one time or another, and they do.
Chris, sorry for the delay in replying.
I understand and agree to your points against compromises in this
context. But my idea of introducing a new keyword such as 'shared'
(as I explained above) was not meant as a compromise, but merely as
another approach to that issue.
The fact that this approach doesn't break existing code, doesn't
automatically mean that it's a compromise. 
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]
