= 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]]''20060818-1501 [SoujaK] [[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 ?
 * 20060725-1758 [gnappo] [[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.