Skip to content
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

Closed
vicuna opened this issue May 8, 2005 · 3 comments
Closed

Cacher constructeurs/etiquettes dans les types private #3620

vicuna opened this issue May 8, 2005 · 3 comments

Comments

@vicuna
Copy link

vicuna commented May 8, 2005

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

@vicuna
Copy link
Author

vicuna commented May 8, 2005

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented May 9, 2005

Comment author: administrator

see also #3621

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

Comment author: @mshinwell

This is a dup of 3621

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant