OpenEuphoria

1. Att: Rob - namespace problem

• Posted by Hayden McKay <hmck1 at dodo.com.au> Sep 22, 2005
• 473 views

There seems to be some "namespace" abnormality under some rare circumstances.

1. I'll demonstrate what I was tryeng to do.
2. I'll demonstrate a hack I found to fix it.

I found this problem while codeing a new bst class for an application.
An extract from the library is something like this...

-- bst.e

constant
    --
    bstNdata = 1,
    bstLeafL = 2,
    bstLeafR = 3

type node(sequence s) return length(s) = 3 end type

sequence bstTree bstTree = {}

global function bstLookup(atom n) -- lookup at bstTree
global function bstInsert(atom n) -- insert at bstTree
-- etc...

Ok. Now I wanted to use multiple Binary Serch Tree's and the easiest way to
do this was to exploit Euphoria's namespace qualifier to create two classes.

-- Too make two instaces of "bstTree" (in bst.e) I did the syntax...

include bst.e as BinaryTableOne
include bst.e as BinaryTableTwo

BinaryTableOne:bstInsert(1)  -- Insert to 1st bstTree Inctance
BinaryTableTwo:bstInsert(2)  -- Insert to 2nd bstTree Inctance

This did not work! Only one instace of "bstTree" existed?  However a valid
work around was to have two copies of the file with two different names ie

include bstOne.e as BinaryTableOne
include bstTwo.e as BinaryTableTwo

BinaryTableOne:bstInsert(1)  -- Insert at 1st bstTree Inctance
BinaryTableTwo:bstInsert(2)  -- Insert at 2nd bstTree Inctance

And presto... it worked!  The drawback is that I need to have multiple copies
of the same bst.e file accompany the source. Maybee this issue could be fixed
in a future release.

Note: The other alterative was to have a function return a handle. And have
      "bstTree" store multiple trees.

3. Re: Att: Rob - namespace problem

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 22, 2005
• 467 views

On Wed, 21 Sep 2005 20:54:46 -0700, Hayden McKay
<guest at RapidEuphoria.com> wrote:

>Ok. Now I wanted to use multiple Binary Serch Tree's and the easiest way to
>do this was to exploit Euphoria's namespace qualifier to create two classes.
Nope ).
>}}}
<eucode>
>-- Too make two instaces of "bstTree" (in bst.e) I did the syntax...
>
>include bst.e as BinaryTableOne
>include bst.e as BinaryTableTwo
>
>BinaryTableOne:bstInsert(1)  -- Insert to 1st bstTree Inctance
>BinaryTableTwo:bstInsert(2)  -- Insert to 2nd bstTree Inctance
></eucode>
{{{

<snip>
>Maybee this issue could be fixed in a future release.
>From past discussions, highly unlikely.
>
>Note: The other alterative was to have a function return a handle. And have
>      "bstTree" store multiple trees.
Yes, the syntax, for comparison with the above, is:

include bst.e
constant BinaryTableOne=newTree()
constant BinaryTableTwo=newTree()

bstInsert(BinaryTableOne,1)  -- Insert to 1st bstTree Inctance
bstInsert(BinaryTableTwo,2)  -- Insert to 2nd bstTree Inctance

D. Newhall wrote:

>That also means that include files in different directories with the 
>same name are treated as the same file and included only once.
Yes, I also consider this a bug. I should really pull my finger out
and post a solution to this for eu.ex.

>This could improve the use of "object oriented" coding techniques and 
>would actually DECREASE the amount of bugs in programs
However I don't think this. The same file in the same directory should
only ever be included once. The technique above which allows newTree's
to be created dynamically at the cost of passing this id to every
function rather than using a namespace qualifier is not particularly
expensive either in terms of typing (about the same) or performance
(in theory, *at most* 20%, rapidly tending to 0% for ops on trees of
any significant size). There would probably be cases where all the
duplicated code causes cache misses so it ends up being slower.

Another point is that if you wanted to reference a tree in more than
one program, presumably you would in the 'class' system code 'include
bst.e as BinaryTableOne' in each source (so the interpreter would have
to maintain a list of previously used namespace qualifiers against
each 'instance' of each include file..); any spelling mistake or typo
in 'BinaryTableOne' would create a new tree, with no possibility of
error or warning, whereas in the 'newTree' approach you would make the
constant BinaryTableOne global, much less error-prone in the long run.

Lastly, changing the interpreter to create a second instance because
the namespace is different would break many, many things.

Regards,
Pete