OpenEuphoria

Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)

• Posted by Pete Lomax <petelomax at blueyonder?c?.uk> Oct 12, 2007
• 868 views

Matt Lewis wrote:

<snip> 
Apart from discussing different Z, I agree with most everything just said.

> Now, on to the masking issue:
> }}}
<eucode>
> -- app.ex
> include lib.e as lib
>   global Z
>   include sublib.e
>     global Z
> include sublib.e as sublib
> ? Z         -- #1 compile error
> ? lib:Z     -- #2 lib:Z
> ? sublib:Z  -- #3 sublib:Z
> </eucode>
{{{


> But what if there is no namespace identifier?  In this case, it's probably
> correct to throw a compile error.  
And that was what I was saying 

> Back to using a namespace.  I'm also thinking that we should only allow
> the "top-level" symbol to mask other symbols.  IOW, I wouldn't use a
> full priority table like you did, but only divide the symbols into two
> groups, the symbols in the explicitly namespaced file, and the symbols
> in all of its includes:

Agreed, that is actually exactly what I do:
> }}}
<eucode>
> --app.ex
> include lib.e as lib
>   include sub1.e
>     global Z
>     include sub2.e
>       global Z
> include sub1.e as sub1
> include sub2.e as sub2
> ? Z      -- #1 compile error
> ? lib:Z  -- #2 compile error
> ? sub1:Z -- #3 sub1:Z
> ? sub2:Z -- #4 sub2:Z
> </eucode>
{{{


My priority table for this would look like this:
   file    parents  priorities
  app.ex    {}       {2,1,1,1}
  lib.e     {1}      {2,4,3,3}
  sub1.e    {2}      {2,4,6,5}
  sub2.e    {3}      {2,4,6,8}

Of course one Z has file number 3 against it and the other has file no 4.
#1: in app.ex, no namespace, so using priorities[1]. 2 Z at pri 1 -> error
#2: namespace "lib" hence using priorities[2], 2 Z at pri 3 -> error
#3: namespace "sub1" hence using priorities[3], 6>5 so use the first one
#4: namespace "sub2" hence using priorities[4], 1 Z at pri >=7 so use it.

The bit you missed is that the {2,1,1,1} and {4,3,3} act like the "only two
groups" you propose, pretty much in all cases I think.

> Consider that if there were no mask, it would be impossible to reference
> sub1:Z.
Yup.
> 
> I believe that this behavior follows these rules:
> 
>   1: Unambiguity and Least Surprise
>   2: Zero impact on legacy code
>   3: Minimal performance impact
> 
Seen that somewhere 

> In fact, now that I think about it, the masking behavior described is 
> required to achieve #2.
Yup, letting a namespace see more stuff means you need to give priority to the
stuff that someone carefully chose the right namespace for.

Regards,
Pete