OpenEuphoria

Re: Weighing in on everything

• Posted by Matt Lewis <matthewwalkerlewis at g?ail.c?m> Apr 28, 2008
• 842 views

Jeremy Cowgar wrote:
> 
> Matt Lewis wrote:
> > 
> > I remain baffled as to why you think it's a good idea to use symbols in
> > files that you don't include.  Maybe it's just me.
> > 
> > How do others feel about this?
> > 
> 
> This is what your talking about right?

No:

-- app.ex
global constant BAR = 1
include foo.e

-- foo.e
include app.ex
? BAR

The "include app.ex" is the "back inclusion."  I contend that this is a
direct, simple and obvious way to indicate that foo.e intends to use
app.ex symbols.  foo.e contains all of the context required to determine
where the symbols it uses come from, even if you encounter foo.e on its
own, you'll know that there's something missing.

But this isn't completely fool proof.  Suppose we have:

-- app.ex
include bar.e
global constant BAR = 1
include foo.e

-- foo.e as f
include app.ex
? f:BAR

-- bar.e
global constant BAR = 2

Notice that we can still manage this, but we need to use a namespace in
foo.e.   The resolution logic uses a symbol in the file with the declared
namespace in preference to one that's included by the file.  In any case
this is likely all one project's code.  A better way to do this might be:

-- app.ex
include bar.e
global constant BAR = 1
include foo.e
set_BAR( BAR )
foo()
-- foo.e as f
integer BAR
global procedure set_BAR( integer bar )
    BAR = bar
end procedure

global procedure foo()
    ? BAR
end procedure

-- bar.e
global constant BAR = 2

Now, app.ex is using foo.e in what I'd describe as a more normal fashion.
Of course, another route would have been to stick the BAR constant 
declaration in a separate file altogether, and let anyone interested
in using it just include that file.

> I don't like that idea of back inclusion. I think it has the potential to
> cause a lot of unnecessary errors. I think if I want access to ABC, I
> should include filea.e.

Here's why you want to allow this.  Consider a large library like win32lib.
There are lots of files, and as a user, you may very well need to be able
to call some of those (think about the structure support).  All you should
need to know is that you have to include win32lib.ew, and you can access
all of the goodness therein.  If the developer decides to refactor, it 
shouldn't matter to you, so long as those things you need to use are still
available.

However, currently, there is no way to stop the propagation of symbols from
win32lib support files that are meant to be internal to the library, though
not the file in which they reside.  CChris, PeteL and I had some lengthy,
though inconclusive discussions a while back.

To boil them down simply, we each had a different implementation in mind,
and I'd characterize mine as the most minimalist, with Pete's next, and
then CChris'.

This is the next place that the namespace/symbol resolution of euphoria
needs to go.

Matt