OpenEuphoria

Re: Namespaces

• Posted by Kat <gertie at PELL.NET> Oct 23, 2000
• 557 views

On 23 Oct 2000, at 3:25, David Cuny wrote:

> How do people prefer namespaces to behave? For example, imagine that you had
> a namespace option in Euphoria like this:
>
>    import <file> into <namespace>
>
> that behaved like include does, but the imported code would have to be
> accessed through the namespace prefix. So if you had a file like this:
>
>    -- test.e
>    global integer number
>
> and you wrote:
>
>    import test.e into foo
>    import test.e into bar
>
> Would you expect 'foo.number' and 'bar.number' to reference the *same*
> variable, or different variables? My thinking is that it would be more along
> the lines of how Euphoria currently behaves to have them refer to the same
> variable. On the other hand, it's awfully convenient for each namespace to
> have it's own local data, like classes.

Unequivocally *different* !!! After all, if i wanted the same data, i'd not use
different
names to get to it. And if Py or Eu has a method to multitask that we haven't
discovered yet (see my previous post on multitasking,, did anyone try that for
me, or
explain why it would not work?), i would not want namespace conflicts to kill
that off.

Now, as an offshoot of this in variable naming, i have tried to write code that
would get
me the same var *in some circumstances* no matter how i asked for it:

%table.top.color
%table.color.top
%color.table.top

could all be the same, but not this:

%top.table.color
or
%color.top.table

Which got into a complicated syntax parsing for the var names, which wasn't my
point
at the time. But my point here is this, if the programmer knows what she is
writing,
and she writes foo.number() in the code, she should not get bar.number(),
especially if
we get threads, and something execs bar(), doing something totally unrelated to
foo(),
changing a local var there that foo.number's processing is/was based on. You
could
get some nasty hard.to.track bugs that way too.

Kat