OpenEuphoria

Re: When will Eu be updated again and more

• Posted by dcuny at LANSET.COM Feb 09, 2001
• 377 views

Robert Craig wrote:

> Also, I'll probably support a file name prefix
> to distinguish between globals with the same name
> in different files.

The problem is, this wouldn't help in the case of a large library like
Win32Lib. In fact, it would possibly make it *harder* to organize libraries.

Consider that, at some point, a large library like Win32Lib eventually needs
to split into smaller parts, in order to better organize the contents.
Here's a trivial example:

   -- mylib.e
   integer local_var

   procedure foo()
      local_var += 1
   end procedure

   procedure bar()
      foo()
   end procedure

   procedure grill()
      local_var += 2
   end procedure

Imagine that I had decided that the library was becoming unweildly, and I
wanted to split the library into three parts:

   -- mylib.e
   integer local_var
   include "part1.e"
   include "part2.e"
   include "part3.e"

   -- part1.e
   procedure foo()
      local_var += 1
   end procedure

   -- part2.e
   procedure bar()
      foo()
   end procedure

   -- part3.e
   procedure grill()
      local_var += 2
   end procedure

Now the code no longer works, because local_var is local. So here's the fix,
using namespaces:

   -- mylib.e
   global integer local_var
   include "part1.e"
   include "part2.e"
   include "part3.e"

   -- part1.e
   global procedure foo()
      mylib.local_var += 1
   end procedure

   -- part2.e
   global procedure bar()
      part1.foo()
   end procedure

   -- part3.e
   global procedure grill()
      mylib.local_var += 2
   end procedure

Now, from a conceptual point of view, this is a Bad Thing. The variable
local_var is local, and should remain that way. Instead, we have to declare
it global, which is the *last* thing we should be doing. So much for data
hiding.

But wait - it get worse. The fix doesn't work because 'foo' isn't defined in
mylib.e, it's now part in part1.e. So I have to access it using the prefix
of the file that it's included from, not the library that it's part of. Ick!

OK, to be fair, this isn't really a namespace problem. But it's closely
related, and it's a real issue - one I run into regularly with any of my
large libraries.

What I'd *really* like to see is an 'include' sort of command that allowed
files to be scoped at the same level as the file they are being included
into. To avoid inventing new keywords (and potentially breaking any code),
I'll just stick an octothorpe in front of 'include':

   -- mylib.e
   integer local_var
   #include "part1.e"
   #include "part2.e"
   #include "part3.e"

Voila! We can now easily divide large libraries into smaller units, not have
to modify any code, and no existing code breaks. Otherwise, namespaces
actuall just make things worse.

One second concern: I hope that there will be a way of using aliases for
prefixes. For example:

   include "win32lib.ew" as w32

Besides the convenience, there's also the issue of case sensitivity. For
example, DOS is not case sensitive, but Linux is. Will the prefixes be
different in both environments?

I'd really like have the ability to specify the prefix, because I'd like to
prefix *all* the calls to libraries by their prefix.

-- David Cuny