Un Mixin per definizione consente di memorizzare i dati in variabili di istanza a livello di mixino?

3

Diverse implementazioni di mixin (ad esempio Ruby mixin, Scala trait) includono il supporto per la memorizzazione di dati (ad es. variabili, proprietà) tra chiamate di metodo in variabili d'istanza. C'è stato un po 'di dibattito in questa domanda sull'opportunità o meno di un metodo di estensione virtuale Java qualificato come mixin perché non è possibile memorizzare i dati in questo modo; tutte le variabili sono immesse ed emesse nell'ambito della chiamata al metodo e non possono essere memorizzate in una variabile di istanza. In sostanza, si è discusso su cosa sia un "mixin" per definizione e se implementazioni o meno in Ruby e quali non vanno oltre la definizione comunemente riconosciuta del concetto di programmazione.

Sfortunatamente, la definizione di un mixin sembra piuttosto vaga a questo riguardo. Ad esempio, Wikipedia dice quanto segue:

With mixins the class definition defines only the attributes and parameters associated with that class; methods are left to be defined elsewhere, as in Flavors and CLOS, and are organized in "generic functions". These generic functions are functions that are defined in multiple cases (methods) by type dispatch and method combinations.

Quanto sopra dice che un mixin definisce gli attributi, ma non cita fonti che potrebbero chiarire questo. Tuttavia, ogni altra definizione semplicemente non riesce a dire se i mixin consentono o meno di memorizzare i dati o se sono limitati a metodi. Per aggiungere ulteriore confusione, Wikipedia descrive in precedenza i mixin come an interface with implemented methods , ma le interfacce non possono memorizzare variabili di istanza. Ho cercato di scoprire come è stato definito in Flavors , che è stato il primo linguaggio di programmazione a utilizzare qualcosa chiamato "mixin", ma non sono riuscito a trovare abbastanza informazioni online al riguardo.

Quindi un mixin per definizione consente di memorizzare i dati? O è qualcosa che è ambiguo e viene lasciato al linguaggio di programmazione per decidere?

    
posta Thunderforge 19.11.2013 - 21:55
fonte

1 risposta

4

Il documento Eredità basata su Mix di Bracha and Cook [ PDF] mostra che l'ereditarietà come trovata nelle lingue Smalltalk , Beta e CLOS può essere reinterpretata come specializzazione dell'ereditarietà del mixin.

Il punto principale qui è che l'ereditarietà può essere vista come un'applicazione lineare di delta astratti in una classe base, ad es.

class Foo {
  int num = 42;
  int doStuff() { return num; }
}

class Bar extends Foo {
  void otherStuff() { return; }
}

- qui potremmo interpretare entrambe le classi come delta: il mix Foo aggiunge un metodo doStuff e un membro num , mentre Bar aggiunge otherStuff . Tuttavia, i mixin non possono essere istanziati da soli (sono astratti). Espresso in questo modo, con mixin composizione tramite l'operatore :

mixin MFoo {
  int num = 42;
  int doStuff() { return num; }
}

class Foo = MFoo ⊕ Object;

mixin MBar {
  void otherStuff() { return; }
}

class Bar = MBar ⊕ Foo
          = MBar ⊕ (MFoo ⊕ Object)

L'ereditarietà classica singola è una specializzazione di mixin in cui ogni delta può essere applicato solo a una singola superclasse ( MBar può essere applicato solo a Foo , ma non anche a Baz ).

Se l'ereditarietà di una singola classe può essere vista come una specializzazione di mixin, allora mixins permetti l'ereditarietà dei dati! Tuttavia, una specializzazione specifica dei mixin non ha bisogno di richiede questo. Sia l'ereditarietà delle classi che le interfacce sono specializzazioni dei mixin.

I metodi di estensione di Java non consentono l'archiviazione dello stato, quindi le interfacce Java 8 non sono in grado di modellare l'ereditarietà della classe. Pertanto, queste interfacce non sono mixin nel senso di Bracha e Cook. Tuttavia, offrono funzionalità di tipo mixin in quanto consentono di ereditare funzionalità da più tipi, fornendo così un tipo debole di ereditarietà multipla.

Restano due punti degni di menzione, sebbene siano tangenziali alla mia argomentazione:

In primo luogo, al giorno d'oggi i tratti sono di gran moda. Questa è un'estensione di mixins che non richiede composizione lineare. Tutti i più recenti sistemi mixin-like implementano effettivamente tratti o almeno li chiamano tali.

In secondo luogo, la logica di progettazione per i metodi di estensione in Java 8 non è principalmente quella di aggiungere mixin, tratti o eredità multipla, ma piuttosto di aggiungere la possibilità di estendere retroattivamente interfacce esistenti per utilizzare nuovi metodi. Si intende che questi metodi di estensione vengano sovrascritti implementando le classi. È importante sottolineare che questo consente di aggiornare l'interfaccia Collection per includere metodi come la funzione di ordine superiore map senza codice di interruzione che ha implementato Collection durante Java 7 volte e quindi non ha implementazione per map .

    
risposta data 19.11.2013 - 23:56
fonte

Leggi altre domande sui tag