Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001828OCaml~DO NOT USE (was: OCaml general)public2003-09-14 00:442016-12-07 17:36
Reporteradministrator 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001828: Compatibilite ascendante des interfaces
DescriptionL'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

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0016746)
shinwell (developer)
2016-12-07 17:36

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

- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue
2016-12-07 17:36 shinwell Note Added: 0016746
2016-12-07 17:36 shinwell Status acknowledged => closed
2016-12-07 17:36 shinwell Resolution open => no change required
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker