OpenEuphoria

Re: Data hiding

• Posted by Matt Lewis <matthewwalkerlewis at gma?l.?om> Oct 17, 2007
• 544 views

Derek Parnell wrote:
> 
> Matt Lewis wrote:
> > I'd be especially 
> > interested in what Rob and Derek think about all this
> 
> So far, I think you have both lost the plot. I can't support much of what
> I can see being suggested. Overly complex, un-intuitive and trying to 
> solve problems I don't think we have.

I sort of agree with you.  There are really two issues being discussed.
There's the issue of symbol resolution, and of data hiding.  You've 
addressed the symbol resolution issue similarly to what I've implemented.

I see two real outstanding issues related to this.  The first is the 
inherited namespaces (see my last response in the symbol resolution thread
to CChris) and whether we allow non-included symbols to be resolved.

I basically agree that data hiding is not a problem per se, but more of
a nice to have feature.

> I think that the current name resolution mechanisms work for all cases except
> one and that is the one that should be fixed. It can be fixed without
> introducing
> new keywords.
> 
> The principle should be that a statement can only reference a symbol 
> that is can know about. And that means the symbol is either defined
> in the same file as the referring statement, or is a global symbol 
> defined in one of the files included (at any depth) by the file with 
> the referring statement. This also means that it cannot be referring 
> to a symbol defined in another include tree that it didn't actually 
> include.

This is essentially what I've done already, with the exception that 
referencing an un-included symbol results in a warning rather than an 
error.  This was largely for backwards compatibility.  I guess it just
depends upon how strict we want to be with this.  As I mentioned,
even the eu source code did this a lot (now fixed in the mwl branch).

<snip>

> Making these rule changes will cover all cases, I believe. No new keywords,
> no un-intuitive concepts to grasp, and solves the one potential problem for
> third party library developers.

Agreed.
 
> The other thing to help would be that when Euphoria detects an ambiguous
> reference, it tells the coder about all the possible places that the
> symbol resides in so the author can decide which namespace to use.

I thought it already does this....[looking]...Ah, I guess it stops
checking once it finds one conflicting symbol.  So the change would be
to keep looking and report all possibilities.  That would be useful.

Matt