Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003620OCamlOCaml generalpublic2005-05-08 04:402005-05-09 15:34
Reporteradministrator 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003620: Cacher constructeurs/etiquettes dans les types private
DescriptionHello,

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

TagsNo tags attached.
Attached Files

- Relationships
related to 0003621acknowledged Re: [Caml-devel] Cacher constructeurs/etiquettes dans les types private (PR#3620) 

-  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


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker