0001828: Compatibilite ascendante des interfaces

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0001828

OCaml

OCaml general

public

2003-09-14 00:44

2003-09-14 18:42

Reporter

administrator

Assigned To

Priority

normal

Severity

feature

Reproducibility

always

Status

acknowledged

Resolution

open

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0001828: Compatibilite ascendante des interfaces

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

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

Relationships

Notes
There are no notes attached to this issue.