Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003621OCamlOCaml generalpublic2005-05-08 21:382008-01-22 16:56
Reporteradministrator 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003621: Re: [Caml-devel] Cacher constructeurs/etiquettes dans les types private (PR#3620)
DescriptionChers Alain et Pierre,

> > 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 | ...

> > pour les types enregistrement:
> >
> > type t = { a = int; b = int; id = string }
> > -->
> > type t = private { a = int; b = int }

Une petite remarque: ces deux possibilités sont déjà disponibles pour
les types à rangée privés (variants polymorphes et objets).
Mais ça ne fait que rendre plus naturel de les avoir pour les types
privés originels.
Les types à rangée privés ne sont pas limités par l'ordre des
étiquettes/constructeurs, mais dans le cas ci-dessus cette limitation
ne semble pas être un problème.
Par rapport au problème de l'égalité structurelle, une solution serait
de reprendre la syntaxe des types à rangée:
  type t = private {a: int; b: int; ..}
Comme ça on sait qu'il y a d'autres champs, qui peuvent intervenir
dans les comparaisons. D'un autre côté cette distinction peut polluer
les interfaces.

> 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

Je ne suis pas sûr de comprendre le "ni à la construction".
Dans l'exemple ci-dessus la question ne se pose pas puisque le
constructeur Foo est lui-même privé?

C'est en effet un propriété intéressante de la représentation des
types variants (pas possible avec les variants polymorphes). Ce qui ne
va pas sans me rappeler l'idée (jamais poussée) de nommer les
paramètres d'un type somme, comme dans un enregistrement.
  type t = Foo of {a: string; b:int}
Mais je crois qu'il faudra garder ça pour un autre langage.

Jacques

TagsNo tags attached.
Attached Files

- Relationships
related to 0003620acknowledged Cacher constructeurs/etiquettes dans les types private 

-  Notes
(0000259)
administrator (administrator)
2005-05-09 15:34

See also PR#3620
(0000260)
administrator (administrator)
2005-05-09 18:34

Cher Jacques,

[...]
> Une petite remarque: ces deux possibilités sont déjà disponibles pour
> les types à rangée privés (variants polymorphes et objets).
> Mais ça ne fait que rendre plus naturel de les avoir pour les types
> privés originels.
> Les types à rangée privés ne sont pas limités par l'ordre des
> étiquettes/constructeurs, mais dans le cas ci-dessus cette limitation
> ne semble pas être un problème.
> Par rapport au problème de l'égalité structurelle, une solution serait
> de reprendre la syntaxe des types à rangée:
> type t = private {a: int; b: int; ..}
> Comme ça on sait qu'il y a d'autres champs, qui peuvent intervenir
> dans les comparaisons. D'un autre côté cette distinction peut polluer
> les interfaces.

Bien sûr, c'est logique d'utiliser aussi le ... pour indiquer les
champs omis comme on le ferait pour les constructeurs omis.

> > 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
>
> Je ne suis pas sûr de comprendre le "ni à la construction".
> Dans l'exemple ci-dessus la question ne se pose pas puisque le
> constructeur Foo est lui-même privé?

Bien sûr. Je voulais juste rappeler que ce champ pourrait être omis
des arguments de la fonction de construction si besoin est (par
exemple, pour alléger la construction des valeurs du type ou bien
parce que le champ est calculé par la fonction de construction
elle-même).

> C'est en effet un propriété intéressante de la représentation des
> types variants (pas possible avec les variants polymorphes). Ce qui ne
> va pas sans me rappeler l'idée (jamais poussée) de nommer les
> paramètres d'un type somme, comme dans un enregistrement.
> type t = Foo of {a: string; b:int}
> Mais je crois qu'il faudra garder ça pour un autre langage.
>
> Jacques

Ce serait élégant d'avoir ce trait pour ce langage-ci aussi. Le
principal problème me semble être le nommage des labels associés aux
constructeurs. Après réflexion, j'avais trouvé

 Constructeur^.label

qui me semble une généralisation ``naturelle'' de la notation en ``.''
qui n'est ni trop lourde ni trop invasive.

--
Pierre


- 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 0003620


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker