You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: