Changes between Version 11 and Version 12 of Variante2

Timestamp:

Aug 27, 2006, 9:15:05 PM (19 years ago)

Author:

soujak

Comment:

Aggiornamento da changeset:22

Variante2

@@ -6 +6 @@
 
 Questo documento e' presente in duplice copia: fra i sorgenti in modo da essere
-facilmente editabile e leggibile in fase di sviluppo, e sul wiki
-[src:/branches/var2/doc/Appunti] e nel wiki [wiki:Variante2] per aumentarne la
+facilmente editabile e leggibile in fase di sviluppo, e sul [wiki:Variante2 wiki]
+e fra i [source:branches/var2/doc/Appunti sorgenti] per aumentarne la
 facilita' di utilizzo. Dal momento che i commenti sul wiki possono essere
 lasciati anche da chi non segue direttamente lo sviluppo, l'utilizzo del file
@@ -59 +59 @@
    cosa a bassa priorita'.''
 
+
+
 == Diaro di bordo: dubbi, problemi e conseguenti scelte ==
+
+=== Il modello ===
+
+200606??-???? [[BR]]
+`Branch`: diventeranno figlie delle `Expression`?
+
+20060820-1238 [SoujaK] [[BR]]
+Natura del modello: la struttura solitamente pensata come un albero di
+espressioni e' rappresentata grazie a campi interni degli oggetti che compongono
+l'aggregato. Si tratta di `List` o `ArrayList` nel caso di nodi non terminali,
+altrimenti tipi specifici (bool, String, int) a seconda del caso. Il problema
+che sorge e' come riuscire a far attraversare un aggregato cosi' eterogeneo da
+un Iterator. [[BR]]
+Forse potrebbe avere senso fare come e' stato fatto per Variante 1, cioe'
+far diventare i campi interni degli `SchemeValue`. Si tenga pero' presente che lo
+SchemeValue e', di per se', gia' un prodotto della valutazione
+
+=== API di manipolazione generica ===
 
 20060725-1758 [gnappo] [[BR]]
@@ -75 +95 @@
 sollevamento di un eccezione).
 
-20060820-1238 [SoujaK] [[BR]]
-Natura del modello: la struttura solitamente pensata come un albero di
-espressioni e' rappresentata grazie a campi interni degli oggetti che compongono
-l'aggregato. Si tratta di `List` o `ArrayList` nel caso di nodi non terminali,
-altrimenti tipi specifici (bool, String, int) a seconda del caso. Il problema
-che sorge e' come riuscire a far attraversare un aggregato cosi' eterogeneo da
-un Visitor o da un Iterator. [[BR]]
-'' Forse potrebbe avere senso fare come e' stato fatto per Variante 1, cioe'
-far diventare i campi interni degli !SchemeValue. ''
+=== API di manipolazione specifica ===
 
 20060820-1332 [SoujaK] [[BR]]
@@ -90 +102 @@
 effettuate all'esterno di esso. Affinche' i `Visitor` riescano nel loro intento
 hanno ovviamente bisogno di conoscere l'oggetto che intendono visitare.
+
+=== Visitor ===
 
 20060820-1817 [SoujaK] [[BR]]
@@ -108 +122 @@
 visita, dal momento che la sua implementazione risiede, in tutte le sue
 componenti, proprio fra i metodi di visita degli oggetti. [[BR]]
-Faro' cosi'.
- 
-=== Appunti vari ===
 
- * Gli iterator sono da intendersi come esterni.
- * I nostri due visitor (!PrettyPrintVisitor e !InterpreterVisitor) conoscono
-   direttamente la natura dell'albero di espressioni su cui lavorano. Al cliente
-   e' chiaramente lasciata la possibilita' di usare un iterator.
- * Le Expression$NAME vanno arricchite con API di manipolazione specifica (i.e.
-   `getter` e `setter`) per permettere all'iteratore di accedere in maniera
-   indiretta ai campi di istanza.
- 
+20060821-1316 [SoujaK] [[BR]]
+Nell'implementazione dell'interfaccia del `Visitor` ho preferito usare nomi
+diversi per i vari metodi (`visitA()`, `visitB()` ...), piuttosto che un unico
+metodo `visit()` sovraccaricato. La chiarezza del codice aumenta. [[BR]]
+20060827-1326 [SoujaK] [[BR]]
+Cosi' facendo ci si gioca la possibilita' di trattare genericamente con delle
+Expression. Nell'implementazione delle operazioni polimorfe questa diventa quasi
+una necessita' poiche' costringerebbe a controllare la classe di appartenenza
+dell'oggetto che vogliamo visitare: si parla di if-else in cascata. Per venire a
+capo della cosa il dott. Solmi aggiunge ai suoi costrutti un metodo ''ad-hoc''
+che permette di identificare il costrutto, mettendolo in corrispondenza con una
+enumerazione.
+
+20060826-2018 [SoujaK] [[BR]]
+Sto iniziando l'implementazione del `VisitorInterpreter`: non devono forse
+riuscire ad attraversare qualsiasi componente del modello, compresi gli stessi
+Value e le Definition, dal momento che si riferisce alle operazioni sul modello
+come '''polimorfe'''?
+
+20060827-1744 [SoujaK] [[BR]]
+Come si gestisce il passaggio delle informazioni indispensabili al processo di
+valutazione, in relazione al pattern `Visitor`?
+Il modo piu' immediato e' inserire, dove necessario, un Environment fra i
+parametri di ingresso e un Value fra quelli di uscita nei metodi accept() e
+visit(). Cosi' si diminuisce l'omogeneita' delle varie Expression e si sporca
+l'interfaccia classica di questo pattern.
+
+20060827-1905 [SoujaK] [[BR]]
+La soluzione per cui ho optato e' quella di utilizare campi interni al visitor.
+Aggiungere ai `Visitor` uno stato interno e' una pratica piuttosto diffusa che
+non intacca l'eleganza del pattern, pur aumentandone le potenzialita':
+ * nel caso della prettyPrint potrebbe essere lo stato potrebbe essere sfruttato
+   come contatore dei livelli di indentazione;
+ * l'`Interpreter` invece potrebbe mantenere uno stack di `Value` e uno di
+   `Environment`.
+
+=== Varie ===
+200606??-???? [[BR]]
+Gli iterator sono da intendersi come esterni. 
 
 
-== Operazioni aggiunte ==
+
+
+== Operazioni aggiunte - `contrib` ==
+
 Questo e' il posto in cui rendere note le proprie scelte.