Determina l'ordine di esecuzione in base alla definizione dichiarativa?

Question

Determina l'ordine di esecuzione in base alla definizione dichiarativa?

#1 da (3 voti)

0

Vogliamo creare un DSL in Scala in cui è possibile elencare in modo dichiarativo gli ingredienti di cui un prodotto è composto. Questi ingredienti possono essere ad esempio "Crea prodotto a", "Crea prodotto b", "Invia mail". Gli ingredienti possono dipendere l'uno dall'altro (ad esempio, "mail" può essere inviato solo una volta che sia il prodotto a che il prodotto b sono stati creati). L'obiettivo è che la definizione degli ingredienti non includa informazioni imperative. Il parser del DSL deve determinare l'ordine di esecuzione corretto in base ai tipi di esempio.

Quindi ad esempio:

"CompletedProduct" consists of { Mail, ProductA, ProductB }

dovrebbe risultare in ProductA e ProductB che viene eseguito per primo (preferibilmente in sequenza, ma questo non è necessario in un primo passaggio), e una volta che questo è finito Mail dovrebbe essere eseguito e una mail dovrebbe essere inviata.

Quali sono i modi possibili per eseguire tale DSL che ha determinato un piano di esecuzione?

scala dsl declarative

posta Erwin Rooijakkers 11.04.2016 - 10:50

fonte

1 risposta

Leggi altre domande sui tag scala dsl declarative

Cerca le voci dell'elenco da un altro elenco, modo migliore? Come strutturare i file client API restful nel progetto C #?

score 3 · Answer 1

Questo non è proprio specifico per i DSL Scala. Hai lo stesso problema con il modello tradizionale di Builder, quando vuoi un costruttore che deve ricevere determinate cose. Al posto dell'ordine di esecuzione è quindi una dipendenza.

Ad esempio, desideri un builder in grado di generare ProdottoA o ProdottoB, ma quando scegli ProdottoA devi specificare un meccanismo di consegna e per ProdottoB hai bisogno di un ID cliente (fondamentalmente solo due cose diverse).

Quello che puoi fare per risolvere questo è lo stesso dei DSL Scala: crei le classi corrispondenti ai singoli passi e invece di restituire questo (o sé), restituisci un nuovo oggetto con le prossime opzioni possibili.

Quindi Builder.createProductA restituisce un ProductABuilder con un metodo "setDeliveryMechanism", mentre Builder.createProductB restituisce un ProductBBuilder.

Nel tuo caso, probabilmente non vuoi che i tuoi utenti DSL inizino a dichiarare in modo dichiarativo un prodotto tramite "Mail". Invece, hai una classe principale DSL che consente la creazione di ProductA o ProductB, ma restituisce una classe "MissingProductB" o "MissingProductA", sulla quale è possibile specificare l'altro prodotto corrispondente. Una volta che hai entrambi, la prossima classe potrebbe essere MissingMail.

Nota che questa struttura di classe corrisponde staticamente alle possibili frasi della tua grammatica DSL.

Qualcosa che è difficile da realizzare con questo approccio è quando vuoi essere in grado di combinare arbitrariamente queste tre cose. È quindi possibile aggiungere una sorta di convalida alla fine (ma è runtime che non esegue la convalida del tempo di compilazione), oppure si dovrebbero creare classi specifiche per tutte le diverse varianti delle chiamate possibili, nel qual caso probabilmente si chiamerà no-joy. / p>