Re: Other Ada Standards (was Re: SIGada Conference)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Robert I. Eachus wrote:

> Dmitry A. Kazakov wrote:
> 
>> Right. But if they are related? Deeply nested generic child units? Does
>> not the language encorage designers to use larger compilation units
>> because otherwise users will be "punished" by larger with/use blocks?
> 
> This was an occasional problem in Ada 83, in Ada 95 I think the only
> major case left to fix is mutually interdependent types.  And it will be
> fixed.
> 
> But as a writer you have to ask yourself, every time you go to with
> something that wasn't in your original design, whether the design was
> wrong, or your implementation is wrong.  I guess I find three about
> equal sized groups of cases:  The original design WAS wrong, the
> implementation chosen is not wrong, but does need more visibility
> (almost always in the body) than was anticipated by the design, and the
> third case, this implementation is wrong, fix it.
> 
> If you take that attitude, the number of with clauses is just not a
> burden.

It is not. As I said, it is a cosmetic issue, in most cases.

But it is definitely a burden for newcomers and for occasional users of
library packages. Imagine, one Ada becomes popular, this means that it will
have thousands of libraries. And alas, it will be used for poorly designed
write-once-run-once applications.

>> I think that we have reached the level of complexity where it becomes a
>> heavy burden for a reader to analyze all with's and use's. Tools might
>> help, but there is still a problem.
> 
> No real argument with that statement, just a warning.  When a project
> does get to that point, you had better be almost finished, or go back
> now and do a redesign.  At MITRE we found that this was one of the
> nicest things about Ada.  When the contractor started complaining about
> slow compiles or needing better tools, it was time to examine the source
> and compare it to the design documents.  Almost always there was a
> particular design problem that needed to be fixed.  Sometimes it was
> "just" a programming problem, but often it reflected too ambitious (and
> unrealistic) requirements or serious hardware problems.

Excellent point. Up to some level of complexity numerous with's definitely
indicate a problem, because we a-priory know that there should a way to do
it right, at *this* level.

> One of my favorite examples involved a lot of kludgeware to merge two
> message streams.  Why merge the message streams?  Well the requirements
> specified a throughput of more messages per minute than one 9600 baud
> connection could handle.  But the actual requirement anticipated that
> many messages over a single channel.  We allowed the contractor to test
> with a 19200 connection, and went back to the government customer to
> figure out if the requirement was real, and we should upgrade the
> communications hardware. (It turned out to be cheaper to upgrade the
> modems than redo the requirements analysis. ;-)

So, change the requirements, if you cannot fulfil them! (:-))

>> True, this the same problem, but it is one level beneath. You are talking
>> about type interfaces, with/use issue is sort of "package interfaces".
>> With type interfaces and abstract types we can hide uninteresting
>> details. Probably it is time to go this way for packages.
> 
> No, it is the same issue.  Interface inheritance will allow a package to
> import several ADTs and combine them in one new type.  But the package
> that contains the interface instantiation will EXPORT all of the
> operations that are collected by the interface.  So users of the type
> created by the interface instance will only need to with (and possibly
> use) one package, not several.

Yes, it would definitely help, but

1. It is still manual. I'd wish to have a method to automate this. I.e. to
create proxy types more easily.

2. Not everything is a type. One might wish to "stream" objects and packages
through another "interface" package.

> You can do, and I do, the same thing today with a succession of type
> derivations, each using a generic mix-in.  Interfaces will make this
> easier. The private part of a package containing a series of mix-ins can
> get pretty long, and you often need to do some renames in the package
> body.  If you want to call this multiple inheritance, fine.  But I think
> of it as constructing a type from component ADTs.  Whether there is an
> isa relationship to several types, or just a record type with several
> component ADTs, the program structure is the same:  The unit that
> creates the ADT has withs for the compontents, users of the created ADT
> need only with one unit.
> 
> If the average number of withs per package is say two per spec and three
> or four per body, you are doing good.  Four per spec and ten per body is
> acceptable in a final product.  But when it looks like you are getting
> beyond that watch out.  Doing the necessary refactoring will take time,
> but it will reduce the number of bugs to be found once coding is
> complete drastically.

This metric is good, but sometimes it can be misleading. If using an
external library it might indicate rather a problem in the library design.
Win32 or UNIX thin bindings are inevitably bad. Then the rule that with-ing
a child implies with-ing the parent causes aberrations in the metric:

with A.B.C.D; -- One with

with A;
with A_B;
with A_B_C;
with A_B_C_D; -- Four

Though semantically the second might be same. For example A_B could be an
instantiation of a generic child of A.

Then "use A.B;" does not imply "use A;", so the number of use's might
explode even if the design is not so afwully bad. The "use all A.B.C;"
proposal might help. But I'd like to have a finer control over what will be
with/use-d, i.e. "interface" packages. It could be a great help for big
libraries. One could make a set of "interface" packages providing different
views on the library, not necessarily reflecting the design of the library.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de