Variante 1

Prodotti estendibili

Note varie

La nostra Clone() e' superficiale, perche' dovrebbe essere soddisfacente per la maggior parte dei clienti, e perche' permette un certo risparmio di memoria. Da menzionarsi in documentazione.

20060724-1715 gnappo & roma
In realta' implementare la Clone() per i prodotti base non e' necessario giacche' la factory istanzia gia' in maniera corretta tali prodotti. Tale funzione diventa invece _indispensabile_ per chi vuole aggiungere nuovi prodotti a run-time per una successiva creazione.

20060725-1559 gnappo
Nota minore:Si potrebbero tipizzare le liste di espressioni attualmente campi di istanza di alcune SchemeExpression (e.g. SchemeExpressionAnd). In tal modo non avremmo necessita' di cast (generici docet).

Tutte le SchemeExpression?<Value> potrebbero avere come campo d'istanza lo scheme value associato (da istanziarsi al momento della creazione dell'espressione) anziche il valore come tipo primitivo. Attualmente gli scheme-value vengono creati solo al momento della valutazione. Se fossero creati subito il metodo prettyPrint potrebbe semplicemente riutilizzare il metodo toString insito negli scheme-valori. La soluzione e' piu' elegante anche se richiede un consumo di memoria leggermente maggiore. (<-la proposta e' stata implementata)
Nello scrivere la prettyPrint ci si accorge dell'esigenza di poter stampare SchemeBranch e SchemeDefinition in quanto contenute in altre SchemeExpression. Le soluzioni percorribili sono dunque due: la prima e' rendere SchemeExpression sia i branch che le definition, la seconda esporre dei getter specifici che ritornano espressioni (trattasi di aggiramento, SchemeBranch gia' li offre). A mio parere la prima implica uno snaturamento di cio' che e' espressione quindi percorrero' la seconda strada.

20060726-1652 gnappo
In un passo delle specifiche riguardanti variante 1 si fa riferimento alla configurazione dei prodotti durante la costruzione. A tal proposito sorge un dubbio riguardo ai prototipi: come favoriamo la configurazione dei prototipi? Attualmente vengono passati degli argomenti al metodo create della prototype factory ma essi vengono ignorati in quanto tale metodo ritorna semplicemente un clone (di piu' non puo' essere fatto visto che non possiamo conoscere come i prodotti futuri dovranno essere configurati). A questo punto in documentazione andrebbe aggiunto: "![...] qualora il cliente prevedesse una fase di configurazione durante la creazione di un prodotto, dovra' egli stesso ridefinire una PrototypeFactory in cui il metodo create assolva a tale compito".

20060727-1725 gnappo
Ho creato la classe SchemeExpressionAbstract: di default solleva eccezione per tutti i metodi previsti nell'interfaccia SchemeExpression. In questo modo chi tentera' di utilizzare la clone sui prodotti di base rimarra' inc*to (UAHAHAHAHA)... Scherzi a parte, potrebbe essere utile per definire altri comportamenti di default (non so ancora per cosa). Ovviamente ora tutte le SchemeExpression di base ereditano da tale classe.

20060731-1742 gnappo
Sempre a proposito di cosa e' expression e cosa no: nelle specifiche originali di MiniScheme viene palesato che una definizione _non_ e' una espressione e tantomeno un branch. La scelta di non uniformarle all'interfaccia SchemeExpression appare, quindi, quantomai corretta. Nel ticket #5 si fa riferimento al prodotto programma: in questo modo potremmo incapsulare la creazione di nuove SchemeDefinition demandando tale compito al nuovo oggetto.

20060924-1658 gnappo
Si potrebbe utilizzare il pattern template method al fine di modularizzare gli algoritmi di valutazione o stampa per le espressioni. Cosi' facendo porzioni degli algoritmi possono essere facilmente riutilizzate dai nuovi prodotti aggiunti dal cliente.

Prodotti aggiunti

Questo e' il posto in cui rendere note le proprie scelte.
gnappo: prodotto che rappresenta funzione di libreria pow. Dati a e b calcola a elevato b (link al codice provvisorio).