1. Namespace Qualifiers
Please forgive me if this has been answered before, but I'm a bit confused.
-- found in User32.ew:
include win_misc.ew
include msgbox.e
include gdi32.ew
-- found in Win32Lib.ew:
include machine.e
include dll.e
include msgbox.e
include file.e
include get.e
include wildcard.e
include image.e
include tk_maths.e
include tk_misc.e
include tk_mem.e
both win_misc.ew and tk_maths.e contain a function called or_all()
when I include both User32.ew and Win32Lib.ew in the same program, I get the
error:
C:\EUPHORIA\include\Win32Lib.ew:1743
a namespace qualifier is needed to resolve or_all
store( icc, INITCOMMONCONTROLSEX_dwICC, or_all( { ICC_WIN95_CLASSES,
If tried including either User32.ew or Win32Lib.ew with a namespace qualifier,
but qualifiers
are local, and I need to include either win_misc.ew or tk_maths.e with a
qualifier.
How do I 'resolve' this with out modifying User32.ew or Win32Lib.ew?
~Greg
g.haberek at comcast.net
2. Re: Namespace Qualifiers
----- Original Message -----
From: "Greg Haberek" <g.haberek at comcast.net>
To: "EUforum" <EUforum at topica.com>
Subject: Namespace Qualifiers
>
> Please forgive me if this has been answered before, but I'm a bit
confused.
>
>
> -- found in User32.ew:
> include win_misc.ew
> include msgbox.e
> include gdi32.ew
>
> -- found in Win32Lib.ew:
> include machine.e
> include dll.e
> include msgbox.e
> include file.e
> include get.e
> include wildcard.e
> include image.e
> include tk_maths.e
> include tk_misc.e
> include tk_mem.e
>
> both win_misc.ew and tk_maths.e contain a function called or_all()
> when I include both User32.ew and Win32Lib.ew in the same program, I get
the error:
>
> C:\EUPHORIA\include\Win32Lib.ew:1743
> a namespace qualifier is needed to resolve or_all
> store( icc, INITCOMMONCONTROLSEX_dwICC, or_all( { ICC_WIN95_CLASSES,
>
> If tried including either User32.ew or Win32Lib.ew with a namespace
qualifier, but qualifiers
> are local, and I need to include either win_misc.ew or tk_maths.e with a
qualifier.
>
> How do I 'resolve' this with out modifying User32.ew or Win32Lib.ew?
You can't. Euphoria's namespace concept does not help us in this situation.
I would reason that because win32lib does NOT include win_misc.ew, either
explicitly or implicitly, that the 'or_all' that win32lib is referring to is
the one in tk_maths.e, which win32lib DOES include. Why Euphoria thinks that
win32lib might be trying to refer to a version of a routine that it had no
knowledge of is weird.
What I need to do is to put namespace qualifiers on every routine that
win32lib references. There must be only a few thousand of those....
----------------
cheers,
Derek Parnell
3. Re: Namespace Qualifiers
- Posted by gertie at visionsix.com
Mar 09, 2003
On 9 Mar 2003, at 10:51, Derek Parnell wrote:
<snip>
> What I need to do is to put namespace qualifiers on every routine that
> win32lib references. There must be only a few thousand of those....
Or
1) put every include you use into the one file, with different names, so there
is no conflict.
2) copy each file you include to another name, with each function renamed in
the process. Include it, then delete it.
3) Get RobC to like i asked, and get Eu access to everything it "knows", like
the includes, the function list, the var names, etc., so you will know to
include it or not.
Kat
4. Re: Namespace Qualifiers
On Sun, 9 Mar 2003 10:51:03 +1100, Derek Parnell
<ddparnell at bigpond.com> wrote:
>You can't. Euphoria's namespace concept does not help us in this =
situation.
>
>I would reason that because win32lib does NOT include win_misc.ew, =
either
>explicitly or implicitly, that the 'or_all' that win32lib is referring =
to is
>the one in tk_maths.e, which win32lib DOES include. Why Euphoria thinks =
that
>win32lib might be trying to refer to a version of a routine that it had =
no
>knowledge of is weird.
>
>What I need to do is to put namespace qualifiers on every routine that
>win32lib references. There must be only a few thousand of those....
So what is the "proper" solution then?
a) change std Eu to automagically resolve duplicate globals based on=20
include level; an included file referencing an included global it
has itself included clearly means that one and no other.
b) get smart; the or_all routine in tk_maths.e and the one in=20
win_misc.ew are nothing if not identical; they should resolve to=20
the exact same bytecode. Better than moaning about a conflict,=20
the interpreter should just take the first; the binder/translator
optimise the second out of existence.
c) extend namespace references somehow at the top level to state that
I=20
mean the "or_all" sub-included by file x rather than the one=20
sub-included by file y?
Pete
5. Re: Namespace Qualifiers
On Tue, 11 Mar 2003 00:38:10 +0000, Pete Lomax <petelomax at blueyonder.co.uk>
wrote:
>
> On Sun, 9 Mar 2003 10:51:03 +1100, Derek Parnell
> <ddparnell at bigpond.com> wrote:
>
>> You can't. Euphoria's namespace concept does not help us in this
>> situation.
>>
>> I would reason that because win32lib does NOT include win_misc.ew,
>> either
>> explicitly or implicitly, that the 'or_all' that win32lib is referring
>> to is
>> the one in tk_maths.e, which win32lib DOES include. Why Euphoria thinks
>> that
>> win32lib might be trying to refer to a version of a routine that it had
>> no
>> knowledge of is weird.
>>
>> What I need to do is to put namespace qualifiers on every routine that
>> win32lib references. There must be only a few thousand of those....
>
> So what is the "proper" solution then?
>
> a) change std Eu to automagically resolve duplicate globals based on
> include level; an included file referencing an included global it
> has itself included clearly means that one and no other.
This would be my preference.
> b) get smart; the or_all routine in tk_maths.e and the one in win_misc.ew
> are nothing if not identical; they should resolve to the exact same
> bytecode. Better than moaning about a conflict, the interpreter should
> just take the first; the binder/translator
> optimise the second out of existence.
Assuming that the bytecodes are identical. That is not always the case.
in one file we have ...
global True = 1
and in another file we have ...
global True = ".T."
> c) extend namespace references somehow at the top level to state that
> I mean the "or_all" sub-included by file x rather than the one sub-
> included by file y?
This is not really an isue because at the top level the normal namespace
qualifier can suffice. The problem is when two independant files are
included and each of them refer to a global in one of their included files.
We should not have to change the source code for the files I have just
included.
--
cheers,
Derek Parnell
