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

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

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

Comments

@vicuna
Copy link

vicuna commented May 8, 2005

Original bug ID: 3621
Reporter: administrator
Status: acknowledged
Resolution: open
Priority: normal
Severity: feature
Category: typing
Related to: #3620

Bug description

Chers 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

@vicuna
Copy link
Author

vicuna commented May 9, 2005

Comment author: administrator

See also #3620

@vicuna
Copy link
Author

vicuna commented May 9, 2005

Comment author: administrator

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

@mshinwell
Copy link
Contributor

These proposals for additions to the semantics of private types have not made any progress for 15 years. @garrigue Do you think we can close this issue?

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Apr 30, 2021
@garrigue
Copy link
Contributor

There is no essential information, and we can resurrect this when we have a clearer plan.

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

3 participants