Re: Data hiding
CChris wrote:
>
> Matt Lewis wrote:
> >
> > 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.
And I'd argue that you're really talking about some sort of efficiency
measure. Something that's complex but powerful isn't necessarily
better or worse than something that's simple and slightly useful. I
was merely talking about the relative complexity of the proposals,
which needs to be judged against the output. Other bullet points
were there to address those things.
> 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.
You might take a look at what I did (it's in both the trunk and mwl branch)
for using that info in the translator (also bound/shrouded code, of
course).
> > 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.
There's no reason that you couldn't have multiple external interface files,
and one or more internal interface files (which all get imported by the
various parts of the library that use them). To go back to your concerns
about the complexity argument, your solution certainly has more flexibility,
and probably slightly more power, but at the cost of a lot of complexity.
Perhaps once we can all get some decent examples, we can put another poll
out there to see what others think. Before that, I'd be especially
interested in what Rob and Derek think about all this--we'll probably
just get another 2 proposals. :)
Matt
|
Not Categorized, Please Help
|
|
