RE: A Problem with v2.4 (for Rob)#2
Hello again,
Pete:
Im not really trying to include two libs with
"include"
but trying to say that
include file1
include file2 as x
should mean globals in both files are visible
to the exw, but the ones in file2 are prefixed
while the ones in file1 are not, which means
they are still different functions even though
they have the same name inside each include file.
The following shows this more clearly.
Derek wrote:
-------------------------------------------------------------------------
Clears as mud. It seems to me that you have made this way too
complicated.
Are you just saying that ...
DoSomething()
should be found in the include file that did NOT have a namespace
because
the reference did not specify a namespace. Is that it?
-------------------------------------------------------------------------
Yes, that's it, but it's very important.
I'll try to show why here just in case the importance isnt that clear.
I also see now why there is some confusion. I havent properly
explained the problem situation, only the solution.
Here, we will be dealing with actual code (except for
the c_func() calls, which can be eliminated and
instead just return a zero).
This means the example code will be able to run.
In the following scenario the function 'CreateWindow()' is used
to represent a generic class of global functions as well as
global variables.
Generic global variables are those which are highly likely to
appear in libraries such as:
hInstance
MainWindow
WM_PAINT
WS_OVERLAPPED
while generic global functions are same except they are
global functions and procedures such as:
CreateWindow()
getstring()
or_all()
The scene looks like this:
We have a lib ew file (file1.ew) and a program (file3.exw)
that we are currently using and it works fine. This file
has a lot of generic globals in it.
Sometime later, we want to add another library (file2.ew)
with lots of the same generic globals in it and call it
from the exw program file along with the original lib.
It wont matter that much if we have indentical function
calls and identical variables, because if we never use them
the binder will remove them (assumed) when we go to exe form.
The two libraries should be able to coexist in the program
with no difficulty, even though they have exactly the
same function and variable names, and lots of them.
I would think this scenario is quite common these days.
Now the actual files...
--The original program consisted of file1.ew and file3.ew
--file1.ew
--Existing, ew library (lib1)
global function CreateWindow()
puts(1, "Creating a window")
hWnd=c_func(...)
return hWnd
end function
--file3.exw
--Existing, exw file that calls lib1 functions
include file1.ew --we want to use "CreateWindow()"
atom hWnd
hWnd=CreateWindow()
So far all we are doing is using an ew library.
Now later, we write a new library, or find another one
to use (file2.ew). The new library has updated functions
(represented by CreateWindowEx) but also has many
other older functions that were also needed in
it's original app, and these also appear in the original
library (file1.ew).
--file2.ew
--New, or possibly just another existing library (lib2)
global function CreateWindow()
atom hWnd
puts(1, "Let's make a window")
hWnd=c_func(...)
return hWnd
end function
global function CreateWindowEx()
atom hWnd
puts(1, "Let's make a windowEx")
hWnd=c_func(...)
return hWnd
end function
Now since we want to use our new library AND the old library AND
our original code, we have to modify the exw file.
We of course have to add the new function calls and new code,
but we shouldnt have to modify any existing code.
Note that anything we change can easily include a prefix,
while that which exists we shouldnt have to add a prefix to:
--file3.exw (modified)
include file1.ew --we want to use the old functions
include file2.ew as Windows --we want to use our new functions.
atom hWnd
--the original function call using the original lib1:
hWnd=CreateWindow()
--the new call using the new lib2:
hWnd=Windows:CreateWindow()
In the modified file, line 5, an error is flagged for
a namespace prefix and the program stops running.
To make matters worse, let's rem out line 7
"hWnd=Windows:CreateWindow()"
changes to
"--hWnd=Windows:CreateWindow()"
and let's instead call the newer function we intended
by adding a line to the end of the exw file:
"hWnd=Windows:CreateWindowEx()"
The new modified file now looks like this:
--file3.exw (modified again)
include file1.ew --we want to use the old functions
include file2.ew as Windows --we want to use our new functions.
atom hWnd
--the original function call in the original lib1:
hWnd=CreateWindow()
--the new call using the new lib2:
--hWnd=Windows:CreateWindow() ------ remmed out
hWnd=Windows:CreateWindowEx() ------ new call
Now we run the program again.
What happens?
Again line 5
"hWnd=CreateWindow()"
flags the prefix error and haults
(as we would have guessed because we modified lines AFTER that error).
Thus, merely the PRESENCE of an identical global in the newer ew file
causes errors that hault the program, even though we arent
calling or using it and we have properly prefixed it.
This could be interpreted as the newer file being the offender,
even though it is properly prefixed.
Keep in mind that we didnt necessarily write the
new file, and we dont want to have to modify that file
either.
Now in the modified file3.exw it's true that if we change the line
"include file1.ew as x"
then we can change the offending line(s)
"hWnd=CreateWindow()"
to
"hWnd=x:CreateWindow()"
and this would solve the problem, but,
this would require our changing EVERY generic function
call and EVERY generic global variable in the whole exw program
to include a prefix. This is exactly what we want to avoid.
The reason i say "EVERY" and not "SOME" is because in theory
we assume that we have to change every global, not just some,
because in some libraries there will be a very high coincidence
of identical names and we wont want to have to go through the whole
file adding prefixes, even though it isnt 'really' every single
variable and function. Once we assume "EVERY", we'll cover
'every' case when we find a solution.
It's also true that we could either change or remove the
offending globals in the new ew (file2.ew) but this
too can be very difficult when there are lots of them.
Now if every global in every file that wasnt included
with a qualifier
was prefixed with something like "guid:" then the program
would run just fine because it would see that
"include file1.ew"
was really
"include file1.ew as guid"
and that
"hWnd=CreateWindow()"
was really
"hWnd=guid:CreateWindow()"
in the modified file3.exw,
except that the prefix "guid:"
isnt nor has to be visible.
With this there is no problem and the code would run fine.
I dont think it would even break any existing code.
CONCLUSION
The way Euphoria is handling the namespace right now is such that
an exw file that calls a library has to use qualifiers if a new
library with identical names might someday be used with it, or else
either the old lib, new lib, or exw file has to be extensively modified.
By using the idea of the implied provisional prefix, this problem
would go away.
Possibly just eliminating the syntax error halting would do it too,
as long as the non-qualified global call was referenced to the
non-qualified file properly.
I think this explains it, finally 
Take care for now,
Al
|
Not Categorized, Please Help
|
|
