comp.lang.ada
 help / color / mirror / Atom feed
* Suggestions needed to split a package
@ 2019-05-24 15:49 A. Cervetti
  2019-05-24 16:14 ` Björn Lundin
  0 siblings, 1 reply; 4+ messages in thread
From: A. Cervetti @ 2019-05-24 15:49 UTC (permalink / raw)


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.
Subroutines in the current package see all the private types and operate directly on record fields and build objects using extension aggregates.
One of the record types contain a vector of the other.

Being private types simply splitting the file and using "limited with" clause  would not be possible, because there would be no visibility of the private part.
I thought to define the types as abstract in the parent package and then derive non-abstract types in children.
Would it be feasible?
I don't know how big would be the impact on current code. 
To further complicate things there is a child module that operates on structure built in the package.

Before embarking on a huge job of modifying the current code I need some suggestions.
Does it make sense what I am planning or would it be better leave thing as they are?

Thanks in advance

A. Cervetti


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Suggestions needed to split a package
  2019-05-24 15:49 Suggestions needed to split a package A. Cervetti
@ 2019-05-24 16:14 ` Björn Lundin
  2019-05-24 20:26   ` Randy Brukardt
  0 siblings, 1 reply; 4+ messages in thread
From: Björn Lundin @ 2019-05-24 16:14 UTC (permalink / raw)


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

-- 
Björn

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Suggestions needed to split a package
  2019-05-24 16:14 ` Björn Lundin
@ 2019-05-24 20:26   ` Randy Brukardt
  2019-05-24 21:21     ` Shark8
  0 siblings, 1 reply; 4+ messages in thread
From: Randy Brukardt @ 2019-05-24 20:26 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]

"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.





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Suggestions needed to split a package
  2019-05-24 20:26   ` Randy Brukardt
@ 2019-05-24 21:21     ` Shark8
  0 siblings, 0 replies; 4+ messages in thread
From: Shark8 @ 2019-05-24 21:21 UTC (permalink / raw)


On Friday, May 24, 2019 at 2:26:04 PM UTC-6, Randy Brukardt wrote:
> "Björn Lundin" wrote in message 
> news:qc9595$ime$1...
> > 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).

The way I've gotten around this is by putting these small subprograms in a nested-package within the body, making *that* package separate, and using renames.

Package Public is
  Type T1 is private;
  Procedure P1;
  Procedure P2;
  --...
End Public;

Package Body Public is
  Package Internal is
    Procedure P1;
    Procedure P2;
  End Internal;
  Package Body Internal is Separate;
  
  Procedure P1 renames Internal.P1;
  Procedure P2 renames Internal.P2;
End Public;

-------
As to making overloaded subprograms separate, is there a way to correct this? That, plus [TTBOMK] not being able to overload subprograms in the library hierarchy seem to be fairly related and could arguably make maintenance easier.

e.g. We can't have both
function Ada.Strings.Equal_Case_Insensitive (Left, Right : String) return Boolean;
function Ada.Strings.Equal_Case_Insensitive (Left, Right : Wide_Wide_String) return Boolean;

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-05-24 21:21 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-24 15:49 Suggestions needed to split a package A. Cervetti
2019-05-24 16:14 ` Björn Lundin
2019-05-24 20:26   ` Randy Brukardt
2019-05-24 21:21     ` Shark8

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox