Quando il codice è considerato una lingua specifica del dominio

3

Oggi un'interessante discussione con un collega. Creeremo un wrapper per i canali di WCF, che gestirà correttamente Close (), Abort () e Dispose (). È preferibile utilizzare questo wrapper.

Un collaboratore ha affermato che era come creare un linguaggio specifico di dominio. Si è opposto all'idea, dicendo che avrebbe imposto un certo modo di lavorare su ogni sviluppatore di software che considerava intrinsecamente sbagliato. Preferirebbe sovraccaricare la parola chiave 'using'. (Ora, AFAIK, questo non è possibile in C #)

Quindi, lo fa? La creazione di un insieme di classi e il loro uso rigoroso invece delle classi di altre librerie (ad esempio l'uso vietato del canale) crea un DSL?

Quando il "codice" diventa un DSL? Ho sempre capito un DSL come una nuova lingua con la sua grammatica, parole chiave, parser, tokenizer, ecc. Il termine sta diventando più vago con l'uso?

class ChannelWrapper : IDisposable
{
    void Dispose(bool disposing)
    {
        ...
        try {
            channel.Close();
        }
        catch (CommunicationException) {
            channel.Abort();
        }
        catch (TimeoutException) {
            channel.Abort();
        }
    }
}
    
posta Diana 30.06.2016 - 14:57
fonte

2 risposte

4

Questo non è un DSL, è semplicemente un'API.

Un'API fornisce una serie di blocchi predefiniti per utilizzare entro la lingua utilizzata dal programmatore dell'applicazione. Se si tratta di un insieme di blocchi da utilizzare all'interno di un altro linguaggio di programmazione che verrà utilizzato da un altro programmatore, è un insieme di collegamenti .

Un linguaggio specifico del dominio è una lingua di nuova invenzione , di solito una più semplice di un linguaggio di programmazione, spesso in cui non -programmer può esprimere contenuti utili. L'HTML è quasi troppo complesso per essere chiamato DSL. I formati di file di configurazione di molti piccoli strumenti sono migliori esempi di linguaggi specifici del dominio.

    
risposta data 30.06.2016 - 15:29
fonte
6

Stai toccando la differenza tra un DSL esterno (una lingua separata con la propria sintassi e semantica) e un DSL interno (un modo per progettare creativamente un'API in modo tale che utilizzarlo sembra un linguaggio diverso, anche se in realtà è ancora legato dalla sintassi e dalla semantica del linguaggio "host").

A volte sentirai anche il termine DSL incorporato per quest'ultimo (e più confuso lo vedrai abbreviato come EDSL ) e solo DSL per l'ex. Questa è fondamentalmente una differenza culturale, ad es. la comunità Ruby utilizza la terminologia DSL interna / DSL esterna, mentre la comunità Haskell utilizza la terminologia EDSL / DSL. Tuttavia, trovo il termine DSL incorporato ambiguo, perché suona più come un linguaggio incorporato in una lingua diversa, ad es. come le regex sono "incorporate" in Perl o LINQ è incorporato in C♯.

Per quanto riguarda la tua domanda in cui il confine è ... Credo che non ce ne sia uno. Ogni lingua è un'API e ogni API è una lingua. La "migliore" è un'API, più "lingua-y" si sente. Progettazione di API è design della lingua.

Questo è particolarmente vero per OO: se torni alla visione di OO di Alan Kay, è strongmente ispirato da ciò che in seguito sarebbe diventato ARPAnet e poi Internet. I computer (oggetti) che sono separati (incapsulati) gli uni dagli altri e hanno una propria memoria privata (variabili d'istanza) comunicano tra loro inviando messaggi (chiamando metodi virtuali). In effetti, ha persino usato il termine "messaging" per quello che oggi chiamiamo "virtual method call", e l'API di un oggetto è ancora chiamato il suo "protocollo", di solito in modo informale, ma in Objective-C ad esempio anche come lingua caratteristica.

Quindi, la metafora e la terminologia della rete sono profondamente radicate nel pensiero di OO. Nelle implementazioni molto iniziali di Smalltalk, non c'erano nemmeno metodi (o oggetti). C'erano flussi di messaggi che fluivano attraverso il sistema, e questi flussi sono stati analizzati, interpretati, riscritti e reindirizzati. Poi, sono emersi un paio di schemi: 1) ci sarebbero stati gruppi di "cose" strettamente correlate nel "mare dei messaggi", questi più tardi diventarono "oggetti", e 2) c'era un modello particolare in cui l'inizio di un messaggio denotava alcune serie di azioni enumerate e il resto del messaggio parametrizzava quell'azione, che in seguito divenne "metodi" e "messaggi".

Nota, come ho parlato di analisi e interpretazione dei messaggi sopra? Non sembra un'implementazione linguistica? Possiamo infatti interpretare ogni oggetto in un sistema OO come interprete per la sua lingua!

Nota, comunque, che la tua API in realtà non sembra affatto "lingua-y". Mentre dicevo che ogni API è una lingua (e viceversa), c'è ancora la questione se sia comunemente riconosciuto come tale. Se si pensa a Rake, Gemspecs, RSpec o all'API Rails Routing in Ruby, ad esempio, quando le persone li guardano, vedranno intuitivamente una lingua e solo in seguito si renderanno conto che è in realtà "solo codice Ruby". OTOH, quando guardo il tuo codice, vedo C♯, non qualcosa di diverso, quindi non si "sente" come una lingua.

Quindi tl; dr

  1. ciò che il tuo collega intende è un DSL interno , ciò che intendi è un DSL esterno
  2. non esiste un chiaro confine tra API e lingua, le buone API sono progettate come le lingue
  3. le lingue sono profondamente radicate nella trama di OO, gli oggetti sono essenzialmente degli interpreti
risposta data 30.06.2016 - 15:32
fonte

Leggi altre domande sui tag