Re: Namespace solution?

new topic     » goto parent     » topic index » view thread      » older message » newer message

>2. Expand the syntax of  'include' so that all globals may have a unique
>prefix
>     attached by the programmer as they are included.
>     example:
>     include file.a as a
>     include file.b as b
>
>     ? a.x          -- prints the x in file.a
>        b.x = 33 -- sets x in file.b to 33
>
>      You would still be free to declare x in your own program file, which
>would
>      be legal and would be referred to as just plain  x    (x = 34)
>
>      Possible problems: What happens if you include an existing program
>which uses
>      the plain 'include' syntax?  These "unqualified" includes would 
>prevent
>you from
>      using variables of the same name in your code. And you might not have
>the
>      ability or inclination to go into those include files to add the new
>syntax. Doing
>      so would mean you'd have a 'customized' package, with all the 
>problems
>      that implies. What if that include file were shrouded?
>

An existing file which uses the plain 'include' format would be no trouble 
in this case.  eg:

in win32lib.ew:

include get.e

x = value(y)

-----------------
in myprog.exw:

include get.e as get

x = get.value(y)

-------------
win32lib uses the traditional 'include' while myprog.exw uses 
'include...as'.  This is no problem since value is only 'visible' to 
win32lib.ew as 'value'.  In myprog.exw it is 'get.value'.  Win32lib.ew 
includes get.e, then myprog.exw includes get.e as get.  The interpreter has 
to detect this and make the 'value' routine no longer available in 
myprog.exw, replacing it with get.value.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu