OpenEuphoria

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

• Posted by Igor Kachan <kinz at pe??rlink.ru> Oct 16, 2007
• 845 views

Pete Lomax wrote:
> 
> Igor Kachan wrote:
> > 
> > Pete Lomax wrote:
> >  
> > > BTW, I've still had zero entries to my data hiding challenge,
> > 
> > I think that the *private* and *local* symbols of Euphoria
> > are hidden well enough, so the problem only stands for
> > the *global* symbols.
> Correct.
> > 
> > without symbol [list]  
> > 
> > So, the scheme is simple.
> > 
> Perhaps too simple for me. The include tree looks like this:
> f1
>  |
>  +-f2
>  |  | 
>  |  +-f3 (defines z3)
>  |  | 
>  |  +-f4
>  |  |
>  |  +-f5
>  |     |
>  |     +-f6 (defines z6)
>  +-f7
> 
> How would you make z6 visible in f7 but not in f5, f2 or f1?
> How would you make z3 visible in f4 and f7 but not in f5, f2, or f1?

I'd prefer just *edit* these files, using Edita, and nothing more -
to rename some globals, copy/paster some files instead of includeing
them etc etc, and to get well readable *new* source files,
without any need to keep in mind some complicated rules of
"local but global" scope with "private but local" import.

> > You can just say about not needed globals,
> > or to block them as hidden:
> > 
> > without symbol abs, void, PI, arcsin, VOID, ABS
> > include misc.e
> > include new_sdl.e
> 
> I would not argue against a simple "ringfence" such as this, it has uses, but
> does not solve the challenge posted. One point about the above that I would
> like to make is that a "without symbol" directive should apply only to the
> next
> include statement, not the next N include statements.


Yes, this your "one point" is good point.

 
> > I do not like all these complicated rules with
> > trees, tables of priority etc etc, I just can
> > not remember who is who in those tables and trees,
> 
> The priority tables are a compiler internal, and like the symbol hash table
> which has been around for donkeys years, it should not be something you need
> to think about when coding. It is just meant to be a way of implementing
> "programmer
> intent" as best as possible.


Yes, I know.


> I agree that it is a bit of a challenge to document
> this stuff without confusing everyone.

Yes, it is the very, the most, important thing!

Regards,
Igor Kachan
kinz at peterlink.ru