= Variante 2 =

== Operazioni estendibili ==

=== Note preliminari sul documento ===
Questo documento intende essere punto di riferimento in fase di sviluppo e germe
della documentazione che accompagnera` il progetto.

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
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
presente nei sorgenti e` da ritenersi una copia della pagina wiki; pertanto
chi effettua modifiche al primo si dovra` preoccupare di sincronizzarlo
tempestivamente con il secondo.

In caso di divergenze di opinioni su una sezione e` preferibile il commento
pittosto della brutale modifica, in modo da tenere traccia delle considerazioni
fatte. Convenzioni utili per i commenti:
 * posporli alla sezione a cui fanno riferimento;
 * usare il carattere ''corsivo'' per indivduarli facilmente;
 * premettere il nome dell'autore accompagnato dalla data.
 

=== Specifiche ===

Si assuma che il numero e la struttura dei costrutti del
linguaggio MiniScheme sia dato e non soggetto a
cambiamenti:
 * Si fornisca l’implementazione di tutti i costrutti originali

Si assuma che il numero delle operazioni polimorfe sia
destinato ad evolvere rapidamente
 * Si fornisca un interprete e una prettyPrint modulari

Il modello deve supportare la definizione modulare di
operazioni.
 * Si vuole supportare la definizione di operazioni modulari sia
   sotto forma di visitors che di iteratori
 * Il modello deve fornire API di manipolazione specifiche e
   generiche
 * L’aggiunta di una operazione non deve richiedere nessun
   cambiamento al modello

Le scelte di design devono essere imposte al cliente.
 * Si vuole imporre al cliente l’uso dei pattern stabiliti (in
   particolare quelli creazionali)
 * Il codice e i pattern non conformi a questa specifica non
   devono fare parte del sistema fornito
[[BR]]''SoujaK 200608181501 [[BR]]
Quali pattern creazionali? E` necessario il redesign di questa sezione, oppure
la vecchia Factory adempie gia` a questo compito? Volendo si potrebbe pensare a
soluzioni alternative, ma reputo la cosa a bassa priorita`.

=== Scelte progettuali ===


=== 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.
 * Branch: diventeranno figlie delle Expression ?
 * gnappo 200607251758 [[BR]]
   Le API di manipolazione generiche sono dei getter e setter che agiscono
   sull'intero modello. Per approfondire seguite il
   [http://www.cs.unibo.it/~solmi/teaching/labss_2005-2006/EserciziProgetto2.pdf
   link]. Se non bastasse vi rimando all'[http://www.cs.unibo.it/~solmi/teaching/labss_2005-2006/esercizi/labss_il_model_iterators.zip esempio]
   del prof. Solmi: prestate attenzione alle classi !LanguageEntity e alle varie
   Abstract* (sono particolarmente chiarificatrici).


=== Operazioni aggiunte ===
Questo e' il posto in cui rendere note le proprie scelte.