Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001828OCamlOCaml generalpublic2003-09-14 00:442003-09-14 18:42
Reporteradministrator 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusacknowledgedResolutionopen 
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
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker