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

Compatibilite ascendante des interfaces #8278

Closed
vicuna opened this issue Sep 13, 2003 · 1 comment
Closed

Compatibilite ascendante des interfaces #8278

vicuna opened this issue Sep 13, 2003 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Sep 13, 2003

Original bug ID: 1828
Reporter: administrator
Status: closed (set by @mshinwell on 2016-12-07T16:36:36Z)
Resolution: not a bug
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

L'interface du module Token de Camlp4 a changé entre 3.06 et 3.07 pour
ajouter un champ dans un type enregistrement (dont les valeurs sont créées
par le code client du module). Ça pose un problème sérieux: il est
impossible d'écrire du code qui va marcher avec les deux versions.

Idem pour Lexing (mais c'est moins grave, ca ne concerne que le code qui
genere des tables de lexing, donc surtout ocamllex).

Dans les deux cas, il y a une valeur par défaut pour les nouveaux champs
qui permet de retrouver le comportement de l'ancienne version, ce qui rend
le problème encore plus frustrant.

Je vois plusieurs approches pour eviter ce genre de choses:

  • exporter des fonctions qui construisent les records; on peut toujours
    ajouter un argument optionnel par la suite. Eventuellement, le type record
    peut-etre rendu abstrait s'il ne doit pas etre inspecté par le code
    client, ou alors private. Ca oblige à prevoir dès la première version
    les records qui pourront etre entendus

  • definir une notion de champ optionnel dans les records, similaire à
    celle des arguments optionnels. Ca demande une extension du systeme de
    type.

  • pour les records susceptibles d'etre etendus, utiliser des objets. C'est
    lourd, parce que ca oblige a definir des classes. On voudrait des
    records extensibles legers.

  • lorsqu'un changement d'interface risque de casser du code, definir
    un autre type et les fonctions qui vont avec, et indiquer l'ancienne
    interface comme etant desuette. Faire le menage de temps en temps,
    pour eliminer les interfaces trop vieilles. C'est tres lourd aussi.

Evidemment, le cas des records n'est qu'un exemble, on imagine facilement
le dual avec des types sommes inspectés par le code client (mais la notion
de "par defaut" est plus vague).

Bref, je ne vois pas solution miracle.

Au moins, capourrait etre bien d'indiquer quelque part la liste exhaustive
des changements d'interface qui risquent de casser du code (mais on s'en
rend compte tres vite, c'est vrai).

-- Alain

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

Comment author: @mshinwell

It's not clear to me that there is anything to be done here.

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