Re: Data hiding
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Matt Lewis wrote:
> > >
> > > 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)
> >
> > 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. "
>
> OK, so that moves to the Pro side.
>
> > > ??? - 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.
>
> Ok, so to summarize, non-unique package names cause errors, which would
> be bad. Best practices will be documented to choose package names that
> are unlikely to be duplicated. Less than ideal, in my book, but if the
> suggestions are followed, it shouldn't be a real problem.
>
> > Well, it looks like at last you read the paper 
.
>
> I've looked at it several times, but either didn't have the time to slog
> through it, or was too tired to figure it out. And each time I read it
> I understood it a little better. Also, IMHO, we're finally on the
> same topic. :)
>
> > I don't agree with the metrics you use for simplicity, but that is
> > another topic.
>
> The metrics weren't really what drove my complexity evaluation. They
> were really based upon my impression of how difficult I found it to work
> out how to use it, and what some of the implications were. The keywords
> were just illustrative, but I think they do a good job in showing that
> your approach has many more "moving parts" and ways that things can
> interact. It just adds up to more things that have to be understood
> and used correctly to get the desired results.
>
Sorry, but this doesnt take into account the range of problems solved or the
flexibility gained. You look only at the input (how many extra keywords, as if
that mattered) and don't check the ouput (the gain in functionality or
flexibility). It's a harmfully one sided way to assess things.
I'd define simplicity as a low enough output/input ratio of sorts, not just the
input.
> Which, of course, doesn't necessarily make it worse, but given the
> choice between two equivalents, I'll prefer the more simple of the two
> nearly every time, so I consider higher complexity to be a Con.
>
> Seeing examples might change my mind, as sometimes it's hard to simply
> visualize. And, of course, I'll always have less trouble understanding
> my own ideas, even if only because I've thought about them more.
>
I may find time this weekend to populate Pete's site, hopefully.
I started tidying up the code for the package implementation, as it also
contains another addition, the share and redefine directives. Since *share* aims
at reducing the use of global variables for interfile communication, it could be
part of the solution, but didn't include it out of simplicity - believe it or
not. Will have to test it again.
Updating CRoutine_id() and friends will take some time, as an extra piece of
info will be needed in the IL: the list of included files parents, plus the new
S_FILE_UPPER SymTab field. No problem with current IL, as the default value of 0
means no packaging. It also has to be known in translated code - the murkier part
(for me). So don't expect the files being posted within the next couple days;
timing is bad too.
> One side benefit that I think would be encouraged by my approach is that
> in the main include file of a library, you'd be more likely to have only
> globals that were meant to be exported (the external interface of the
> library). So intra-library API stuff that needed to be shared among the
> files but that you wanted to hide would be put into its own file, and
> imported by the other parts of the library. It would leave less stuff
> in that interface file. I often go to the code to figure out how to
> use it (in lieu of the docs). There would be a lot less stuff to
> filter out.
>
Is this always a good idea?
If a library covers several fields of functionality, it would make sense, to the
contrary, for interface symbols to apear in the relevant domain subinclude,
rather than in the all purpose main file. GUI libs are an obvious example, and
they are currently the most complex libs written in Eu AFAIK - Pete already wrote
about this. The subinclude files may need common services from both the main file
or common subsub include files.
Using the main file may be avoided if the interfile API is confined in some
library level scope aka package - back to square one.
> Anyway, not really important, but an interesting side effect, I think.
>
> Matt
CChris
|
Not Categorized, Please Help
|
|
