1. This shouldnt be..
Robert, when I have a file named test.ex containing this:
include libA.e
include libB.e
And libA contains:
global constant RIGHT = 1
And libB contains
constant RIGHT = 2
Then I run Text.Ex and I get:
"Attempt to redefine RIGHT"
I should be able to redefine something locally, esspecially when the
offending file is *NOT* including the file where the first decleration exist
itself.
If I swap the files, things *do* work.
Now, we're at the name-space problem again, Robert, what would you think of
the Modula2 type of approuch.
Within an include file, order remains as crucial as it is now. However, if
file A includes file B and file B includes file A, then they should both
have acces to each other global routines. Even beginnings would consider
this to be more logical.
Why is the order of include files so crucial ? I understand its not easy to
support this, but it is certainly the most logical thing. And when file A
does *not* directly include file C it should be accesable at all. I know
this would break some code, but as Ive noticed when your shroud a library,
only the global routines of that current library are kept global (as you
told me), which would break that same code anyway.
Ralf
2. Re: This shouldnt be..
On Sun, 8 Nov 1998 14:47:56 +0100, Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
wrote:
>Robert, when I have a file named test.ex containing this:
>
> include libA.e
> include libB.e
>
>And libA contains:
>
> global constant RIGHT = 1
>
>And libB contains
>
> constant RIGHT = 2
>
>Then I run Text.Ex and I get:
>
>"Attempt to redefine RIGHT"
>
>I should be able to redefine something locally, esspecially when the
>offending file is *NOT* including the file where the first decleration exist
>itself.
>
>If I swap the files, things *do* work.
>Now, we're at the name-space problem again, Robert, what would you think of
>the Modula2 type of approuch.
This name-space thing actually *is* a real problem. With a
program of any complexity, it gets tiring to try and fight it.
What about a suggestion (made earlier by someone) that the
global variables be accessed as follows:
libA.x = {something}
libB.x = {something else}
This leaves the private variables to be accessed only by the file
in which they appear - just like private variables within a
function or procedure are only visible within that func/proc.
An alternative (stolen from Pascal) is:
with libA do
x = {something}
y = {something else}
end with
Come to think of it, I like the second option better:
It would allow code like this:
with Company do -- the include file Company.e, get
company[NAME] = "Widgets, Inc." -- the sequence company
-- the constant NAME
and
with Employee do -- different include
employee[NAME] = "Joe Blo" -- sequence employee
-- constant NAME
where NAME could be two different values if needed.
Think about it, please.
Regards,
Irv
3. Re: This shouldnt be..
>Come to think of it, I like the second option better:
>It would allow code like this:
>
>with Company do -- the include file Company.e, get
> company[NAME] = "Widgets, Inc." -- the sequence company
> -- the constant NAME
>and
>
>with Employee do -- different include
> employee[NAME] = "Joe Blo" -- sequence employee
> -- constant NAME
>
>where NAME could be two different values if needed.
>Think about it, please.
Actually, something in that line would be nice.
But, yet many problems would occur, because of the demand of order, not to
mention, what to do, when a file is indirectly included as well as directly
(where the indirect include occurs first)..
Order of include files, should just not matter at all.
If, and only if, file A *directly* includes file B, all global identifers
should be available.. even if file B had already *directly* included file A.
Consider libA.e--------
include libB.e
? libB_function ()
function libA_function ()
return "alright!"
end function
Consider libB.e--------
include libA.e
? libA_function ()
function libB_function ()
return "alright"
end function
---------------
This should work. Within a file mutal recursion shouldnt be possible without
routine pointers, however, throughout multiple include files, mutal
recursion should be possible.
Ralf
