Problèmes de renommage.

[DrPi]

Bonjour,

Voici un problème que j'ai un peu de mal à expliquer.
J'ai, d'une part, un package (pkg1) qui définit les registres d'un
micro-controlleur. S'y trouvent également des déclarations de types et
de variables (en mémoire) qui composent les registres.
D'autre part, j'ai un package (pkg2) qui définit des procédures de plus
haut niveau et qui utilise le package précédent.
Dans un niveau encore supérieur, disons "main", les procédures de pkg2
sont appelées. Mais pour cela, les types et variables déclarées dans
pkg1 sont nécessaires.
Dans un soucis d'abstraction, comment faire pour que, dans "main", je
n'ai pas à importer pkg1 ?


Je schématise avec le code suivant :

-- pkg1 - registres de bas niveau
package pkg1 is
type t_type1 is ...;
var1 : t_type1 := ...;
end pkg1;


-- pkg2 - niveau au dessus de pkg1
with pkg1
use pkg1

package pkg2 is
-- ligne magique pour importer pkg1 visible de main -- <======== (1)
var2 : t_type1 renames var1; -- <======== (2)
t_type2 ??? renames t_type1; -- <======== (3)
procedure init_reg(reg : in t_type1; ...);
end pkg2;


-- main - utilisation de pkg2
with pkg2;

procedure main is
reg : pkg2.t_type2;
begin
reg := pkg2.var2;
pkg2.init_reg(reg=>reg, ...);
end main;


(1) : Peut-on "importer" pkg1 dans pkg2 et rendre le contenu de pkg1
visible de main à travers pkg2 ?
(2) : Cette ligne compile mais est-elle correcte ?
(3) : Peut-on renommer un type ? Comment ?


Nicolas

[J-P. Rosen]

Le 30/04/2020 à 23:56, DrPi a écrit :
[...]

Non. Ceci dit la question pose un problème philosophique. Si (comme
c'est souvent le cas) Pkg1 est l'interface de bas niveau (AKA LLI) et
Pkg2 l'interface de haut niveau (AKA HLI), comment se fait-il qu'un type
de bas niveau soit accessible au haut niveau?

Si il y a vraiment besoin de types communs, alors on peut les mettre
dans un paquetage "Common_Types" utilisé à la fois par pkg1 et pkg2.

> (2) : Cette ligne compile mais est-elle correcte ?

Oui, sinon elle ne compilerait pas ;-)

> (3) : Peut-on renommer un type ? Comment ?

On ne peut pas renommer un type. En revanche on peut:
Faire un sous-type:
subtype T_type2 is Pkg1.T_type1;
Avantage: léger
Inconvénient: n'importe pas les opérations primitives

Faire un type dérivé:
type T_type2 is new Pkg1.T_Type1;
Avantage: importe les opérations primitives
Inconvénient: nécessite de rajouter des conversions dans certaines
opérations.


--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

[DrPi]

Dans le package de bas niveau, j'ai, par exemple :

-- Slew Rate Enable
type PCR0_SRE_Field is
(Fast,
Slow)
with Size => 1;
for PCR0_SRE_Field use
(Fast => 0,
Slow => 1);

Dans le package de plus haut niveau, je définis une procédure
procedure SetSlewRate(sr : in PCR0_SRE_Field) ;

Dans "main", j'aimerais pouvoir faire "SetSlewRate(Fast);".

Je peux redéclarer Fast et Slow dans le package de plus haut niveau
(d'où ma question sur le renommage de types), mais le code peut vite
devenir lourd à écrire...
Peut-être que mes (trop) longues années d'utilisation du C m'ont rendu
fainéant ;)

> Si il y a vraiment besoin de types communs, alors on peut les mettre
> dans un paquetage "Common_Types" utilisé à la fois par pkg1 et pkg2.

J'utilise des packages de bas niveau qui sont générés de façon
automatique par un outil (svd2ada). Donc, pas de souplesse à ce niveau là.
Les packages de plus haut niveau sont écrits par moi.

>
>> (2) : Cette ligne compile mais est-elle correcte ?
> Oui, sinon elle ne compilerait pas ;-)
>
>> (3) : Peut-on renommer un type ? Comment ?
> On ne peut pas renommer un type. En revanche on peut:

Ok.

> Faire un sous-type:
> subtype T_type2 is Pkg1.T_type1;

Ca, je l'ai déjà essayé.

> Avantage: léger
> Inconvénient: n'importe pas les opérations primitives
>

Léger, c'est au niveau compilation ou au niveau exécution ?

> Faire un type dérivé:
> type T_type2 is new Pkg1.T_Type1;

Ca, je n'y avait pas pensé.

> Avantage: importe les opérations primitives
> Inconvénient: nécessite de rajouter des conversions dans certaines
> opérations.

Oui, bien sûr...

[J-P. Rosen]

Le 01/05/2020 à 19:54, DrPi a écrit :
> Dans le package de bas niveau, j'ai, par exemple :
>
> -- Slew Rate Enable
> type PCR0_SRE_Field is
> (Fast,
> Slow)
> with Size => 1;
> for PCR0_SRE_Field use
> (Fast => 0,
> Slow => 1);
>
> Dans le package de plus haut niveau, je définis une procédure
> procedure SetSlewRate(sr : in PCR0_SRE_Field) ;
>
> Dans "main", j'aimerais pouvoir faire "SetSlewRate(Fast);".
>
> Je peux redéclarer Fast et Slow dans le package de plus haut niveau
> (d'où ma question sur le renommage de types), mais le code peut vite
> devenir lourd à écrire...
> Peut-être que mes (trop) longues années d'utilisation du C m'ont rendu
> fainéant ;)

OK, dans ce cas je pense qu'il faut garder le HLI aussi indépendant que
possible du LLI. Le LLI ne bougera jamais, mais le HLI peut évoluer en
fonction des besoins des utilisateurs, ou de l'expérience acquise en
l'utilisant. Cela plaide pour redéfinir un type indépendant du type
d'origine, ou de faire différemment, comme deux procédures Set_Slew_Fast
et Set_Slew_Slow.

>> Faire un sous-type:
>> subtype T_type2 is Pkg1.T_type1;
> Ca, je l'ai déjà essayé.
>
>> Avantage: léger
>> Inconvénient: n'importe pas les opérations primitives
>>
> Léger, c'est au niveau compilation ou au niveau exécution ?

Dans le sens que ça n'impacte que de façon minimale les utilisateurs.

[DrPi]

Merci pour toutes ces infos.

[Thomas]

In article <5eab498a$0$4039$426a...@news.free.fr>, DrPi <3...@drpi.fr>
wrote:

> Dans un soucis d'abstraction, comment faire pour que, dans "main", je
> n'ai pas à importer pkg1 ?
>
>
> Je schématise avec le code suivant :

> -- pkg2 - niveau au dessus de pkg1
> with pkg1
> use pkg1
>
> package pkg2 is
> -- ligne magique pour importer pkg1 visible de main -- <======== (1)

> (1) : Peut-on "importer" pkg1 dans pkg2 et rendre le contenu de pkg1
> visible de main à travers pkg2 ?

pourquoi
package p1 renames pkg1;
ne convient pas ?

ça ne répond pas à ton cahier des charges de "ne pas importer" ?
devoir appeler pkg2.p1 ça n'est pas "visible à travers pkg2" du fait
qu'il faut "entrer" dans p1 ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/