New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cacher constructeurs/etiquettes dans les types private #3620
Comments
Comment author: administrator Bonjour,
Je pense que ces extensions sont sans problème si l'on accepte en Avec Damien nous envisagions des champs privés encore plus radicaux: type t = Foo of (private int) * string Cela ne pose pas non plus de problème difficile de compilation et Merci de ta suggestion.Pierre |
Comment author: administrator see also #3621 |
Comment author: @mshinwell This is a dup of 3621 |
Original bug ID: 3620
Reporter: administrator
Status: closed (set by @mshinwell on 2016-12-07T17:11:32Z)
Resolution: duplicate
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Related to: #3621
Bug description
Hello,
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.
-- Alain
The text was updated successfully, but these errors were encountered: