Re: Data hiding (was symbol resolution)
Matt Lewis wrote:
>
> 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.
Seems pretty reasonable and straightforward to me. I've copied this to my site,
with the additional comments:
-- A new keyword "import" acts like "include" but restricts the visibility
-- of globals to the directly importing file.
-- 25.e
-- Data shared by f2 and f5 only
global integer z2=2
-- 3467.e
-- Data shared by f3, f4, f6, and f7 only
global integer z3=3
-- 467.e
-- Data shared by f4, f6, and f7 only
global integer z4 = 4
-- 67.e
-- Data shared by f6 and f7 only
global integer z6 = 6
Obviously in the context of this abstract challenge, those comments are fairly
meaningless, but if you had an actual reason for doing this stuff, they should
make much more sense.
> OO code has an easy/obvious way to get more granular
Yes, let's not forget that.
> Anywho, this thread makes for an interesting read:
> <a
> href="http://www.openeuphoria.org/cgi-bin/esearch.exu?thread=1&fromMonth=9&fromYear=9&toMonth=B&toYear=9&keywords=%22private+include+files%22">http://www.openeuphoria.org/cgi-bin/esearch.exu?thread=1&fromMonth=9&fromYear=9&toMonth=B&toYear=9&keywords=%22private+include+files%22</a>
Yes, include vs. global include has an elegance I rather like, and I could
easily live with the backward incompatibility it introduces. Maybe there is a way
to introduce this as a "torrent of warnings" rather than outright breakage of
legacy code?
> 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.
Same with "import", surely?
> 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?
My shared scopes idea offers nothing in that respect.
The simple ringfence/firewall idea would be my choice.
> 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.
Correct, and as intended. I am more concerned with offering the option of
sharing things without making them global than I am with coping with stuff which
is already global. As author of libPete my primary concern would be to prevent
users messing with MY data, or calling internal routines they ought not. Now if
libPete upsets libMatt, the critical point to me would be that either I can stop
doing that, or Matt can change libMatt to prevent me, at which point I cannot
really complain, can I?
Regards,
Pete
|
Not Categorized, Please Help
|
|
