SWT e class inheritance

I widget SWT non consentono l'eredità: al loro interno esiste un metodo (checkSubclass()) che effettua dei controlli per garantire che una sottoclasse non venga utilizzata in una applicazione.
Ovviamente questa è una restrizione a run-time, di fatto i componenti possono essere derivati da altri anche se poi non risulteranno utilizzabili a run-time.
Le motivazioni di questa scelta progettuale risiedono nella preferenza della composizione rispetto all'ereditarietà, e mi fa molto piacere vedere che esistano dei framework che si spingono in questa direzione.
Tuttavia ogni tanto è piu' comodo derivare widget da altri piuttosto che usare la composizione (che costringe l'utilizzo di interfacce e la costruzione di API wrapper), ma questo dovrebbe avvenire solo per widget per cui sia garantita la portabilità. Se non si vuole poi implementare la propria logica di controllo nel metodo checkSubclass() è necessario inserire i widgets in un package org.eclipse.swt.widgets.

Spring: RowMapper e avanzamento del ResultSet

I ResultSet passati ad un RowMapper di Spring sono già posizionati sulla prima riga utile, quindi non è necessario fare il classico ciclo alla JDBC:

while( rs.next() ){
...
}

Qualora si debba iterare fra piu' righe del ResultSet occorre convertire il ciclo in un do-while:

do{
...
}while( rs.next() );

SWT: Combo box con modello integrato

Il widget Combo della libreria SWT non consente l'inserimento nel drop down menu' di oggetti qualunque, ma solo di String. Questa è ovviamente una limitazione perché richiede che il combobox sia affiancato da un modello dati che consenta la correlazione fra indice selezionato e oggetto a cui ci si riferisce.
Creare un wrapper per il Combo che contenga un semplice modello dati lineare (monodimensionale) è un'operazione quasi banale. Nell'esempio sottostante si suppone che BusinessObject sia il capostipite degli oggetti che si vogliono selezionare tramite il Combo; questo wrapper rende il comportamento di Combo piu' simile al suo duale Swing JComboBox.

public class BusinessObjectCombo extends Combo {

  public BusinessObjectCombo(Composite parent, int style) {
super(parent, style);
  }

  /**
   * An internal list to keep track of all elements this combo is displaying.
   */
  private List model = new LinkedList();


  /**
   * Provides the business object corresponding to the selected element in the combo.
   * @return the business object from the combo
   */
  public synchronized final BusinessObject getSelectedBusinessObject(){
// get the selected index
int index = this.getSelectionIndex();
// return the element from the model
return this.model.get(index);
  }

  /**
   * Adds a new business object to the combo and to the internal model.
   * @param newElement
   */
  public synchronized final void add(BusinessObject newElement){
// check arguments
if( newElement == null )
    return;
else{
    // add the element to the list and to the combo
    this.model.add(newElement);
    this.add( newElement.toString() );
}
  }

  /**
   * Removes the specified element from the combo.
   * @param element
   */
  public synchronized final void remove(BusinessObject element){
// get the index from the model
int index = this.model.indexOf(element);
if( index >= 0 ){
    this.model.remove(index);
    this.remove(index);
}
  
  }


  /**
   * Clears all the elements from the combo and the internal model.
   */
  public synchronized final void clear(){
this.model = new LinkedList();
this.removeAll();
  }


  /**
   * Adds all the elements from the specified collection.
   * @param businessObjects
   */
  public synchronized final void addAll(Collection businessObjects ){
for( BusinessObject bo : businessObjects )
    this.add( bo );
  }

}

if( opensource instanceof NonHaValore )

Questo non vuole essere un post-flame sull'OpenSource, e non ha nemmeno la pretesa di essere un post di evangelizzazione. Voglio solo enfatizzare un modello comune di pensiero, quasi un paradigma, che si è diffuso e che è difficile da sradicare in molti sviluppatori, designers, software house, ecc. E ovviamente è un paradigma che limita l'adozione dell'OpenSource.

Quando si parla di soluzioni OpenSource spesso si viene bloccati con affermazioni del tipo "ma se poi mi si rompe, o non va, io (il mio cliente, il cliente del mio cliente, l'amico del cliente del cliente, ...) a chi mi rivolgo?". Detta in altre parole: "vorrei tanto usare l'OpenSource, ma non ho le garanzie di una ditta commerciale alle spalle che mi possa offrire un servizio di assistenza".

E' vero!
Ma se parliamo di piccoli progetti OpenSource. Se parliamo di soluzioni di classi enterprise (qualche esempio: PostgreSQL, MySQL, Eclipse, OpenSolaris) allora le aziende alle spalle ci sono, i contratti di assistenza ci sono, i bugfix ci sono. Quello che manca, nella controparte, è la mentalità.
Le affermazioni della controparte possono essere riscritte con altre parole: "pago perché voglio la garanzia di un'assistenza futura".
Scusa ma cosa paghi?
Paghi il prodotto. Allora perché pagando il prodotto hai diritto all'assistenza futura? Perché paghi anche un contratto di assistenza, ma allora paghi il prodotto e l'assistenza.
E se l'azienda fallisce? Chi ti fornirà assistenza?
Ma le grosse aziende non falliscono! Molte volte questo è vero, ma molte volte le grosse aziende vengono inghiottite da aziende ancora piu' grosse (per fare un esempio si pensi al caso Oracle-MySQL). E in quei casi l'azienda potrebbe cambiare direzione, potrebbe smettere un prodotto considerato obsoleto o un doppione di un prodotto presente in entrambe le parti che partecipano alla fusione.
E l'interoperabilità? Beh, quella solitamente va a braccetto con l'OpenSource, perché se le applicazioni sono OpenSource allora gestire i dati e i flussi di dati risulta concretamente fattibile. Se le applicazioni sono closed-source allora tutto si complica, e spesso ci si deve affidare a programmi di import/export creati dall'azienda stessa o un suo partner. E questi non sempre hanno in mente le vostre esigenze, quindi siete spesso voi a dovervi piegare alle loro. Ma come, pagate il prodotto, pagate l'assistenza, e non ricevete nemmeno il classico servizio che anche un ristoratore vi offre (il cliente ha sempre ragione)?
Ma si sta scendendo nella polemica.

Quello che realmente secondo me deve essere enfatizzato è che la mentalità attuale porta a dire che se una cosa è OpenSource (o peggio ancora free) allora non ha valore. Se lo sviluppatore stesso non si fa pagare significa che non sa quanto valga, e comunque deve valere poco.
Io preferisco pensare che abbia talmente tanto valore da non essere misurabile, e che il vero business dietro all'OpenSource sia il servizio.

E metto in guardia i fanatici: non tutto deve rispettare le quattro libertà della licenza GNU GPL. Il Web 2.0 ha portato sistemi che non possono materialmente rispettare la freedom 0 (capacità di eseguire il programma). Ma questo non significa che si debba cedere sull'OpenSource!

Compile time constraints and runtime constraints: WhiteCat merges both!

Due to the reviews on a WhiteCat paper I received, and the claims from a colleague of mine, I decided to write a little post about my way of thinking OOP and how I conceive it with WhiteCat.

I started developing serious applications using Java version 1. If you remember, at that time there were no fancy features, so the only thing you could have to do to decouple your code was to have a good OOP design. What is a good OOP design? It is a strictly typed system.
Am I a strictly-typed kind of developer? Yes.

In my early stage of software designer I was used to create classes and interfaces as it was raining cats and dogs! Then I read THE book about Perl (Programming Perl) and a statement by Larry Wall really impressed me: Larry wrote that there must a balance between programming-in-a-rush and programming-by-presumption. What does it mean? It means (to me) that if you are a pure OOP designer/developer you will start thinking that you are not developing only a piece of software to solve an assigned problem, but you are creating a creature that everybody could/would use. This leads to a class/interface storm, since you are taking into account every possible use of your piece of software. I was such a developer!
Now I've changed my mind, and I've found a good balance between rush and presumption.

How does my OOP mindset connect to the WhiteCat approach? Well, of course WhiteCat is a creature of mine, and therefore it has been developed following my ideas and design/developing habits. But this of course not the answer you want to read.

WhiteCat is a very dynamic system, and usually dynamism is at the opposite of strong typing (think to Python for instance). Since I am a strictly-typed designer/developer, how can I accept a very dynamic system like WhiteCat?

Short answer: Liskov substitution principle is guarantee to work, so the type system is ensured to work.

Do you need a more detailed answer?
When you compile an application you accept the compiler rules. A strict compiler leads to a typed system (secure), while a weak compiler leads to an untyped system (more dynamic, less secure).
WhiteCat agents, roles, and framework itself is compiled thru a standard Java compiler (well, to be onest thru an AspectJ one), so WhiteCat components obey the same compiler rule.
But WhiteCat allows developers to dynamically change the class definition at runtime; does it means that compile rules are overtaken? No, since WhiteCat guarantees the Liskov substitution principle to work. But this is not all folks: WhiteCat imposes compile-time constraints at runtime! This is the very soul of WhiteCat: being able to start from a strongly-typed system (your agents/role compiled thru a Java compiler) and to modify them at runtime as they were compiled in a different way (i.e., starting from modified sources).
So WhiteCat starts from a typed system and leads to a typed system, but in the middle it is able to change the types in order to improve your agents/roles.

Was this the same as RoleX (a.k.a. BlackCat) did? No, because BlackCat was changing dynamically the agent class making the Liskov substitution principle not applicable. In other words, BlackCat was very dynamic, but started from a typed system to get to an untyped (and unmanageable) system. This is the real difference between WhiteCat and BlackCat.

PGDay 2009

Ebbene anche quest'anno ci siamo: ITPug sta organizzando (assieme a tutti i volontari e gli appassionati di PostgreSQL) l'edizione 2009 del PGDay (PostgreSQL Day).

Questa edizione, a differenza di quelle passate, sarà a solo carattere nazionale (il PGDay Europeo si sta svolgendo in questi giorni in Francia). Questo però non significa che la qualità tecnica del meeting sarà inferiore a quella degli altri anni, anzi...basta dare un'occhiata al programma (ancora in costruzione) per accorgersi che non manca davvero nulla per iniziare ad usare o approfondire la propria conoscenza di questo RDBMS.

Forza ragazzi, diamoci da fare!