Data hiding (was symbol resolution)
- Posted by Matt Lewis <matthewwalkerlewis at ??ail.com> Oct 15, 2007
- 588 views
Pete Lomax wrote: > BTW, I've still had zero entries to my data hiding challenge, nor has anyone > set a better one: > http://palacebuilders.pwp.blueyonder.co.uk/dhc.htm OK, here's how my 'import' scheme might handle this test. Basically, I created some extra files where I put the data, and only import them where required. This is a bit clumsy, although I'd probably point out that more than likely, fewer extra files would be needed, unless you really felt the need to hide code from other parts of the same library. Or possibly the modularity of the include files, a la what I've done with the eu.ex code. OO code has an easy/obvious way to get more granular with having different scopes for class members (public/private/protected/ friend/etc). The procedural alternative seems to be to to explicitly specify the imported symbols at the point of use (e.g., perl). There are many aspects of perl that I like, but that's not one of them. Anywho, this thread makes for an interesting read: http://www.openeuphoria.org/cgi-bin/esearch.exu?thread=1&fromMonth=9&fromYear=9&toMonth=B&toYear=9&keywords=%22private+include+files%22 I readily admit that my idea is not as comprehensive or as granular as your or CChris' proposals, but I think it's easier for end users to understand, and that it does have some other benefits. One weakness, perhaps, is that as soon as someone uses include instead of import, the cat's out of the bag--after that, it seems that the symbol has to be visible. But I think that's just a manifestation of the fact that people will abuse code, and there's really nothing we can do about it. One [unstated] criterion I've been using is that declaring "shared scope foo" within the files to be packaged causes those files to be more tightly coupled than I'm comfortable with. It basically seems to require editing the files themselves to be able to hide the symbols. IOW, suppose you were writing libPete, and using libMatt within libPete. You don't want to expose any of libMatt to libPete users. How do you do this? Your shared scope seems to require the source file to hide symbols, but no way to make that firewall to limit the propagation of symbols once they break the initial file with a global declaration.
-- f1.exw: integer z1=1 -- only visible in f1 include f2.e include f7.e ?z1 -- (local) --?z2 -- error --?z3 -- error --?z4 -- error --?z5 -- error --?z6 -- error --?z7 -- error -- f2.e: import 25.e include f3.e include f4.e include f5.e --?z1 -- error ?z2 -- (local) --?z3 -- error --?z4 -- error --?z5 -- error --?z6 -- error --?z7 -- error -- f3.e: import 3467.e --?z1 -- error --?z2 -- error ?z3 -- (local) --?z4 -- error --?z5 -- error --?z6 -- error --?z7 -- error -- f4.e: import 3467.e import 467.e --?z1 -- error --?z2 -- error ?z3 -- OK ?z4 -- (local) --?z5 -- error --?z6 -- error --?z7 -- error -- f5.e: import 25.e integer z5=5 include f6.e --?z1 -- error ?z2 -- OK --?z3 -- error --?z4 -- error ?z5 -- (local) --?z6 -- error --?z7 -- error -- f6.e: import 3467.e import 467.e import 67.e integer z6=6 --?z1 -- error --?z2 -- error --?z3 -- (maybe) --?z4 -- (maybe) --?z5 -- error ?z6 -- (local) --?z7 -- error -- f7.e: import 3467.e import 467.e import 67.e integer z7=7 --?z1 -- error --?z2 -- error ?z3 -- OK ?z4 -- OK --?z5 -- error ?z6 -- OK ?z7 -- (local) -- 25.e global integer z2=2 -- 3467.e global integer z3=3 -- 467.e global integer z4 = 4 -- 67.e global integer z6 = 6