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

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