From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,
	PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Suggestions needed to split a package
Date: Fri, 24 May 2019 15:26:02 -0500
Organization: JSA Research & Innovation
Message-ID: <qc9k0q$tah$1@franka.jacob-sparre.dk>
References: <9fd1cb3d-6e81-47bb-afd2-cae1cd3658a1@googlegroups.com>
 <qc9595$ime$1@dont-email.me>
Injection-Date: Fri, 24 May 2019 20:26:02 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="30033"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader01.eternal-september.org comp.lang.ada:56380
Date: 2019-05-24T15:26:02-05:00
List-Id: <comp.lang.ada>

"Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
news:qc9595$ime$1@dont-email.me...
> Den 2019-05-24 kl. 17:49, skrev A. Cervetti:
>> A package in the program I am writing is getting too long.
>> So I thought it would be a good idea to split it.
>>
>> The package is here: 
>> https://github.com/andreacervetti/ada-virt-monitor/tree/master/avm/src/monitor 
>> (files monitor-structures.ad*).
>>
>> My problems are:
>> I'd like to avoid forcing clients of the package to "with" too many 
>> modules.
>> I want keep private types private.
>
> If it is only file size that is your concern, you
> can look at moving some functions via 'separate' to other files.
> It does not change your structure, and clients of
> the package does not know -> not more withs than current solution

Yes, although if there are a lot of small subprograms, it's not very 
effective as you would end up with a *lot* of files (making it hard to find 
things and slowing compilation). And you can't make overloaded subprograms 
separate (the names have to be unique).

But besides that, you've specified an impossible problem. If you split 
something, you necessarily end up with more units - that's the point. And 
more units mean more "withs". As with everything, there are trade-offs. If 
there are natural divisions, putting some parts into child units may make 
sense. Users that need *everything* would have more withs, but few users 
need everything. So only people that need some subsystems would need to with 
those; that is often the best strategy. But of course every case is 
different.

                                Randy.