OpenEuphoria

Re: Data hiding

• Posted by CChris <christian.cuvier at agric?lture.gouv.f?> Oct 16, 2007
• 544 views

Matt Lewis wrote:
> 
> 
> I've been thinking about this topic, and I've identified several issues.
> I can think of two basic methods to restrict visibility:
> 
>   1.  From within the declaring file
>   2.  From outside the declaring file
> 
> We have a decent mechanism for restricting visibility based on #1, but
> lose all control once it gets out.  The solutions proposed by Pete and
> CChris are what might be called hybrid methods.  
> 
> For reference, here are the links to these two approaches:
> <a
> href="http://oedoc.free.fr/Packages.htm">http://oedoc.free.fr/Packages.htm</a>
> <a
> href="http://palacebuilders.pwp.blueyonder.co.uk/dhc.htm">http://palacebuilders.pwp.blueyonder.co.uk/dhc.htm</a>
> (Pete, your links to the various replies are broken--missing the '#'.)
> 
> CChris' approach provides the package+identifier and restrict lists, which 
> are mostly #2 based, but the addition of the new internal and exported
> keywords earn them a hybrid status.
> 
> Pete requires a #1 approach, but also relies a bit on #2 to enable 
> visibility.
> 
> Both used explicitly named scoping mechanisms, which throw up red flags
> in my mind.  They might not be a problem, but I'd be interested to hear
> from the respective authors what happens when the same name is used in
> two different places, for different purposes.  IOW, does it cause an
> error?  Are the two scopes treated as one?  Etc...
> 

> One concern I have about CChris' approach is that once a symbol is exported
> from a package, there's no way to hide it from downstream users:
> 
>   "An exported symbol is visible from any part of the system."
> 
> Here's a scenario where I think you'd want to be able to do this.  You
> have a library that relies on another library for some backend work.  But
> you don't want to expose any symbols from that library, which might have 
> already restricted visibility on some symbols, and therefore have exported
> some of its symbols.  Is there a way to do this, CChris?  Maybe the 
> restrict keyword does this, but I'm not sure from the documentation.
> 
> Pete's system seems to be a lot simpler, but doesn't offer the ability
> to do this either.  
> 
> Now for an overview on how I'd implement import.  For the file that issued
> an import statement, it would be identical to an include.  For files
> that either include or import that file, no imported symbols would be
> visible, unless included or imported via another route.  This approach
> doesn't rely on any explicit grouping, or knowing which files "belong" to 
> which group.  It just defines the way global symbols propagate, allowing 
> the coder to stop the propagation at any point.
> 
> It's an admittedly minimalist approach, but that's part of what I like
> about it (and why I think it's particularly suited for euphoria).
> 
> ex:
> }}}
<eucode>
> -- myapp.ex
> include libMatt.e
>     import libPete.e
>         global object PETE
> 
> -- PETE is visible from libMatt.e
> -- PETE is not visible from myapp.ex
> 
> --myapp.ex
> include libMatt.e
>     import libPete.e
>         global object PETE
> 
> include libPete.e
> 
> -- PETE is visible from libMatt.e
> -- PETE is visible from myapp.ex
> </eucode>
{{{

> 
> Here is my [quick] evaluation of the current proposals:
> 
> CChris:
>   Pro - gives "transitional" capability to hide info from outside file
>       - high granularity of symbols to hide/expose
> 
>   Con - seems overly complicated (5 new keywords, total 7 different uses)
>       - can't "firewall" symbols (unless that's what restrict does)
> 

 From the short presentation section in Packages.htm:
"restrict <symbol> from <current context> to <new context> 
Customises the scope of a symbol, in the rare cases the tools above won't help."

So yes, it does firewall a single symbol, in cases this is not covered by file
wide approaches. It can also extend it if the rules firewall a symbol too
narrowly.

See also, in the discussion of the "with package" directive:
"Once the scope of a symbol has been defined by its active package, it can be
changed only by a *restrict* directive. "

>   ??? - how will package naming conflicts be dealt with
> 

 From the end of the introduction:
"Since a package is the way to specify that a few source files belong to a
single logical entity, the library, irrespective of their being clustered in one
or more directories, the package identifier should be chosen so as to be very
likely unique. Concatenating the library name, author name and version number
should be adequate."

There is a typo in the posted text, I'l correct it.

In my implementation, an error is raised if a package name appears in two
different *package* directives. I'll mention that explicitly.

Now that I think about it, adding the version info in the package name isn't a
good idea either. The rest should be enough.

Well, it looks like at last you read the paper  . I don't agree with the
metrics you use for simplicity, but that is another topic.

> Pete:
>   Pro - simple implementation (2 keywords [assuming shared_scope = 1 word])
>       - high granularity of symbols to hide/expose
> 
>   Con - requires editing source files
>       - can't "firewall" symbols up the include chain
> 
>   ??? - how will shared_scope naming conflicts be dealt with?
> 
> Matt (import approach):
>   Pro - very simple implementation (1 new keyword)
>       - can hide/firewall symbols at any point in include chain
> 
>   Con - granularity of other proposals achievable, but requires changing
>         file layout (i.e., moving variables to files that are imported)
> 
> I'd be interested in hearing from people other than us 3. :)
> 
> Matt