Manière classique de résoudre le besoin d'une dépendance croisée

Salut,

Je suis en train d’étendre un programme et je me retrouve dans la situation pas cool où j’aurai bien envie d’avoir une dépendance croisée. En gros, quelque chose comme:

fragile.mli/ml:

(* MLI *)

type abstract

val operation: unit -> unit
val query: abstract -> unit

(* ML *)

type abstract = {
  not_important: int
}

let hidden () =
  let a = { not_important = 42 } in
  (* B.register a ; <- ce que j'aimerais pouvoir faire *) 
  a

let operation () =
  ignore( hidden () ) (* en vrai forcément, on fait des trucs avec *)
  
let query some_abstract_thing = () (* et en vrai on a une info intéressante ici *)

Et table.ml:

let register some_abstract_thing =
  (* mettre ça dans une table *)

let query params =
  let some_abstract_thing = (* collecter le bon dans la table *) in
  Fragile.query some_abstract_thing (* pour récupérer l'info planquée chez fragile *)

Dans l’idée, j’aimerai bien éviter de faire gonfler encore le module Fragile, ou même simplement de faire des modifications trop conséquente dessus parce qu’il est assez critique, mais pour ça je me retrouve dans la solution pas jolie d’une inter-dépendance (à cause de l’opération commentée plus haut dans Fragile).

Du coup si quelqu’un a une manière classique de résoudre ça.

Merci d’avance.

Passe une fonction en paramètre de hidden ?

let hidden callback () =
  let a = { not_important = 42 } in
  (* B.register a ; <- ce que j'aimerais pouvoir faire *)
  callback a;
  a

Le callback semble raisonnable. Sinon une autre solution crade c’est d’avoir val registrar : (abstract -> unit) ref dans Fragile, et faire

let () = Fragile.registrar register

dans Table.

Ceci dit, on doit faire ces choses pas très jolies à cause d’APIs qui ne sont déjà pas très reluisantes au départ. Pourquoi cacher autant d’état mutable dans Fragile, et refaire pareil dans Table ? Idéalement on aurait l’interface suivante pour Table:

type table
val empty: unit -> table
val collect: table -> Fragile.abstract -> table
val query: table -> params -> Fragile.abstract

et ensuite dans le code utilisateur

Fragile.query (Table.query tbl params)

Je ne suis pas sûr de voir en quoi le callback peut vraiment m’aider. Parce que je n’ai pas de levier pour transmettre la fonction en question de l’extérieur. Ça changerait l’API de Fragile.

Bouahahah, c’est moche . J’aimerais bien éviter d’en arriver là. Mais effectivement, ça reste à envisager .

Oui, les APIs en question ne sont plus de première jeunesse (et c’est bien empiré par le fait que ce sont des monolithes assez mastocs). Ceci dit j’ai un peu caché une partie des détails aussi dans mon explication. En réalité, du côté de Fragile, les tables en question n’existent que pendant une durée limitée, à moins qu’un utilisateur malin ne les conserve, d’une manière pas nécessairement pratique et générique aujourd’hui, et la requête ne s’applique qu’à un seul de ces états.

Le but de ce module externe est justement d’éviter que ces données soient jetées pour faciliter par la suite d’autres analyses, sans pour autant exposer le contenu du record en question. Une autre différence est la possibilité d’appliquer transitivement "query" qui est plutôt de la forme:

val query: table -> t -> t

Sur une série de table de correspondances.

Une autre option, ça pourrait être de sortir complètement "abstract" et son API de Fragile dans un module différent, mais je pense que la quantité de travail ne serait pas très raisonnable.