OpenEuphoria

Re: More Namespace

• Posted by "Lucius L. Hilley III" <lhilley at CDC.NET> Oct 02, 1999
• 485 views

Maybe, we could use local.

You have include file.e naturally makes it global.
however we could confine it with local.

include file.e

local include file.e

With local the globals are only available to the program
that included it.

Take this for example though.
--machine.e--
global constant TRUE = 1
------------------

-- graphics.e--
include machine.e
----------------

--aninc.e--
local graphics.e
global true = TRUE
---------------

--program.ex--
include aninc.e

? true -- print 1
? TRUE -- should fail because the include and all
       -- its includes have been localized.
--------------

We could use local or localize.  Localize is a bit more descriptive.



        Lucius L. Hilley III
        lhilley at cdc.net   lucius at ComputerCafeUSA.com
+----------+--------------+--------------+----------+
| Hollow   | ICQ: 9638898 | AIM: LLHIII  | Computer |
|  Horse   +--------------+--------------+  Cafe'   |
| Software | http://www.cdc.net/~lhilley |  USA     |
+----------+-------+---------------------+----------+
                   | http://www.ComputerCafeUSA.com |
                   +--------------------------------+
----- Original Message -----
From: David Cuny <dcuny at LANSET.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Saturday, October 02, 1999 1:56 AM
Subject: Re: More Namespace


> ---------------------- Information from the mail
header -----------------------
> Sender:       Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster:       David Cuny <dcuny at LANSET.COM>
> Subject:      Re: More Namespace
> --------------------------------------------------------------------------
-----
>
> I agree that there should be a namespace modifier. I was thinking of
> something like 'friend' or 'module'.
>
> Here's one use of 'friend': you have a library that's a single file, and
> you'd like to break it up into parts. Writing:
>
>     include friend <module name>
>
> tells Euphoria that the routines are shared, but are not global.
>
> Here's another example: Let's say that I wanted to use Neil in my library.
I
> could write:
>
>     include friend neil.e
>
> And Neil would be visible to my library, but not to the routines that are
> using my library. If I wanted the Neil routines to be global, I would
write:
>
>     include global neil.e
>
> and all the routines declared as global in Neil would really be global.
>
> Under this kind of setup, the keyword 'global' should really be replaced
> with 'export' - it defines the interface to the library routines, but it's
> up to the include routine to decide if the routines are global or local to
> the module.
>
> -- David Cuny
>