OpenEuphoria

1. Data hiding (was symbol resolution)

• Posted by Matt Lewis <matthewwalkerlewis at ??ail.com> Oct 15, 2007
• 589 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

3. Re: Data hiding (was symbol resolution)

• Posted by Matt Lewis <matthewwalkerlewis at gmail?co?> Oct 16, 2007
• 608 views

Pete Lomax wrote:
> 
> Matt Lewis wrote:
> 
> > 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
> 
> 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?

It was this thread, I think, that initially inspired my "import" idea,
but sorta going in the opposite direction, in part because it won't break
any legacy code, but manages effectively the same thing.  Reversing this
to make a non-global include needs a 
 
> > 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?

Yes and no.  Using the libPete/libMatt example, if you wanted to hide
libMatt symbols from libPete, then you'd need to edit libMatt.  Or 
possibly create a wrapper that imported libMatt and therefore hid 
the the rest of libMatt.  I was more thinking about being able to hide
libMatt from libPete users, which your approach doesn't handle.
 
> > 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?

I agree with your goal, but the issue I was thinking about was that from
the perspective of libPete, libMatt is an implementation detail, and users
should not be messing with it.  Maybe next release uses libRob instead
of libMatt.  As long as users were kept away, this shouldn't be a problem.
Well, they could still use libMatt, but they'd have to include it themselves.

Longer post (which I'd started when this one showed up) to follow...

Matt