OpenEuphoria

Re: Data hiding

• Posted by Derek Parnell <ddparnell at b?gpond.com> Oct 17, 2007
• 577 views

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 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.


If X is defined as global symbols inside fileA and fileB, then statements in
fileA can never refer to the X in fileB and visa versa, unless fileA includes
fileB in which case the author of fileA must use namespaces to disambiguate.

To put it another way, if fileA  refers to X it is referring to the X in fileA.
If fileB refers to X it is referring to the X in fileB. If subsequently, fileA
and fileB are both included together in fileC, there should still not be a clash
and they still refer to the same X that they did before being included. If fileC
refers to an X, the author of fileC must disambiguate using namespaces.

Also, enable the file name to be an automatic namespace.

  include fileB.e
  include fileA.e

  a = fileB:X
  b = fileA:x


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.

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.


-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell