Come gestire configurazioni rigide a livello di componente?

Question

Come gestire configurazioni rigide a livello di componente?

#1 da (2 voti)

1

Distinguo tre livelli di organizzazione durante la programmazione: il livello di libreria, il livello di componente e il livello di applicazione. Una libreria definisce le funzioni per risolvere una serie di problemi correlati o operazioni relative alle preforme in modo strumenti e nessuna politica . Un'applicazione consente a più librerie di interagire e definisce le politiche per la diagnostica, la gestione degli errori, l'internazionalizzazione, ... Un componente si trova tra la libreria e l'applicazione, gestisce errori di basso livello e produce diagnostica, potrebbe avere un vecchio stato globale ed è a conoscenza di altri componenti.

Ora ho implementato una libreria come un functor parametrizzato da un modulo che ha una costante n e i valori associati a diversi valori di n hanno tipi incompatibili, che è lo scopo di implementare la libreria come un funtore. Io chiamo tale configurazione una configurazione difficile , perché in qualche modo deve essere hard-coded nel programma.

Ora sto affrontando il seguente problema: In questa impostazione, voglio consentire all'utente del programma di scegliere il valore di n per la durata del programma. Poiché la libreria è un funtore, ci si sente obbligati a scrivere come componente il componente che interfaccia la libreria al programma. Ma voglio che il valore scelto di n sia una proprietà del componente, non dell'applicazione, e voglio che i componenti siano moduli regolari (nessun functor permesso).

Come posso avvolgere una libreria parametrica (implementata come un funtore) in un componente non parametrico, in modo che i parametri possano essere scelti all'avvio dell'applicazione? Insisto sul fatto di poter esprimere la logica dell'applicazione al massimo livello in termini di moduli non parametrici, e voglio evitare moduli parametrizzati simili a quelli delle bambole russe a questo livello.

design ocaml

posta user40989 30.12.2013 - 12:52

fonte

1 risposta

Leggi altre domande sui tag design ocaml

Posso rinominare una porzione di codice rilasciata con Apache 2.0? La copertura delle condizioni ha una copertura marginale?

score 2 · Accepted Answer

Questo suona esattamente come il caso d'uso previsto dei moduli di prima classe:

A typical use of first-class modules is to select at run-time among several implementations of a signature.

link

Un altro pensiero sarebbe quello di implementare i parametri di configurazione del componente come celle mutabili, qualcosa del genere:

module Component :
sig
  val init : ?foo:int -> ?bar:float -> ?baz:string -> unit -> unit
  val foo : unit -> int
  val bar : unit -> float
  val baz : unit -> string
end = struct
  module Default =
  struct
    let foo = 0
    let bar = 0.
    let baz = ""
  end
  let store_foo = ref Default.foo
  let store_bar = ref Default.bar
  let store_baz = ref Default.baz
  let init ?(foo=Default.foo) ?(bar=Default.bar) ?(baz=Default.baz) () =
    ( store_foo := foo
    ; store_bar := bar
    ; store_baz := baz
    )
  let foo () = !store_foo
  let bar () = !store_bar
  let baz () = !store_baz
end