0003620: Cacher constructeurs/etiquettes dans les types private

Notes
(0000257) administrator (administrator) 2005-05-08 11:14	Bonjour, > Une petite proposition pour améliorer les types privates: la possibilité > de pouvoir cacher des constructeurs et des étiquettes, pour nettoyer > les interfaces de détails d'implémentations que l'on ne veut justement > ne pas exposer. > > Exemple, pour les types sommes: > > type t = A \| B \| C of int \| D of string > --> > type t = private A \| B \| C of int \| ... > > (on autorise seulement des préfixes des ensembles des constructeurs > constants et non constants; les ... servent à pouvoir détecter les > filtrages incomplets). D'ailleurs, ces ... pourraient aussi servir > pour des type non private, pour indiquer explicitement qu'on autorise > des filtres wildcards sur ce type sans provoquer le warning "this > pattern is fragile". > > > pour les types enregistrement: > > type t = { a = int; b = int; id = string } > --> > type t = private { a = int; b = int } > > (ici, on n'a même pas besoin de spécifier qu'il y a autre chose; les > champs cachés doivent être en position finale). > > Autrement dit, le module cache completement l'existence de certaines > étiquettes. Le seul soucis sémantique que je vois, c'est que la notion > d'égalité structurelle (=) permet de découvrir que des enregisterements > qui ont les même champs visibles sont pourtant différents. Je pense que ces extensions sont sans problème si l'on accepte en effet que l'égalité structurelle sur les types privés avec ... n'est pas forcément celle qu'on croit. Avec Damien nous envisagions des champs privés encore plus radicaux: des arguments de constructeurs non visibles au filtrage (ni à la construction), seulement utiles pour des besoins d'implémentation correcte du type à constructeurs privés. type t = Foo of (private int) * string --> type t = private Foo of string Cela ne pose pas non plus de problème difficile de compilation et c'est intéressant pour avoir un champ privé par constructeur si nécesaire. Merci de ta suggestion. -- Pierre

(0000258) administrator (administrator) 2005-05-09 15:34	see also PR#3621

Issue History
Date Modified	Username	Field	Change
2005-11-18 10:13	administrator	New Issue
2008-01-22 16:56	doligez	Relationship added	related to 0003621