Post by J-P. RosenPost by Bladyprocedure Proc is
package Pac is end;
package Pac.Fils is end; -- illégal
begin
null;
end;
Est-ce différent ?
Oui, ce n'est pas spécialement dans une procédure, c'est dans n'importe
quoi...
La notion d'enfant est définie pour des /unités de compilation/, donc
pas pour des unités imbriquées dans une autre unité de compilation. Le
but des unités enfant était de réduire les temps de compilation, de
permettre d'incorporer ou non des parties d'un composant logiciel, de
permettre de rajouter des fonctionnalités sans tout recompiler... Bref,
des use cas liés à la notion de compilation.
Honnètement, je ne vois pas trop le use case d'un paquetage enfant à
l'intérieur d'une autre unité. On peut avoir le même effet en mettant
Fils à l'intérieur de Pac.
Bin, je comprends bien les raisons justifiant la création des unités
enfants.
Mon utilisation réside dans la création de petits programmes d'essais ou
d'exemples ne tenant que dans un seul fichier source pour une
communication plus simple, par exemple:
procedure Ex_Paquetages_Enfants is
-- Une fois déclaré un paquetage Parent :
package Parent is
-- ...
end;
-- Le paquetage enfant est déclaré comme suis :
package Parent.Fils1 is
-- ...
end;
...
Pour les unités de compilation GNAT requière un fichier distinct par
unité que je pourrais mettre dans une archive zip ou alors l’utilisation
de gnatchop. Ce qui reste moins accessible ou immédiat pour un
utilisateur débutant.
D'autre part, ne serait pas possible de lever cette interdiction pour
une meilleure orthogonalité du langage ?
Merci, Pascal.