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 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

SoujaK 200608181501
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
  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'​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.