venerdì 10 luglio 2009

Ereditarietà multipla in Scala

Il problema dell'ereditarietà multipla nei linguaggi fortemente tipizzati (C++) è, molto banalmente, che se un oggetto eredita da due differenti classi che implementano lo stesso metodo, il compilatore non sa quale implementazione di quel metodo associargli (bind).

In Java e in C# perciò si è deciso di abolire l'ereditarietà multipla, e di inserire il concetto di interfaccia. Il problema delle interfacce, però, è che attraverso di loro viene descritto il comportamento di un oggetto (quali metodi sicuramente quel metodo avrà), ma non viene implementato, perché l'implementazione si demanda alla classe di quell'oggetto.

Questa soluzione non è ottimale, perché se nella mia tassonomia di classi ho delle forti "somiglianze" tra una classe e l'altra, la scrittura dell'implementazione dell'interfaccia comune rischia di doversi ripetere da una classe all'altra. Insomma, rischiamo ripetizioni e riscritture.

In Ruby esiste il concetto di mixin, per cui posso "prendere a prestito" del codice che esiste "altrove" e inserirlo nella mia classe, senza doverlo riscrivere. Il problema è che Ruby è un linguaggio di scripting, e non è tipizzato.

Scala è invece un linguaggio tipizzato che permette - in un certo senso! - l'ereditarietà multipla, e lo fa attraverso i "trait".

Ecco un esempio:


abstract class Animale
{
def nome:String;
def classe:String;
def comeMiChiamo:String = ("Sono il " + this.nome + " e sono un " + this.classe);
}

trait Mammifero extends Animale
{
override def classe:String = "Mammifero";
}

trait Rettile extends Animale
{
override def classe:String = "Rettile";
}

class Delfino(aName: String) extends Animale with Mammifero
{
def nome:String = "delfino "+ aName;
}

class Serpente(aName: String) extends Animale with Rettile
{
def nome:String = "serpente "+aName;
}

object Main
{
def main(args: Array[String])
{
parla(new Delfino("Pippo"));
parla(new Serpente("Pluto"));
}

def parla(animale: Animale)
{
println(animale.comeMiChiamo);
}
}


In questo esempio, la classe Animale è una classe astratta, che definisce il metodo "comeMiChiamo" (ok, non mi veniva niente di meglio!). Questo metodo è polimorfico rispetto alla "specie" dell'animale. Definisco perciò due nuove classi, che incidentalmente sono anche "classi di animali": i rettili e i mammiferi.

L'output del programma in console è:


Sono il delfino Pippo e sono un Mammifero
Sono il serpente Pluto e sono un Rettile


Quello che voglio dimostrare, è che posso scrivere in Scala una classe che eredita sia da Animale (il metodo "come mi chiamo"), sia da Rettile oppure Mammifero. Per farlo, "Rettile" e "Mammifero" sono due trait, di fatto la trasposizione dei Mixin per Scala. Se vogliamo, sono delle interfacce, solo che, a differenza delle interfacce in Java, il metodo che espongono è anche già implementato - evitandoci riscritture e copia/incolla nel codice (che è sempre male).

PS: La questione della duplicazione dei metodi alla base del problema dell'ereditarietà multipla, non è risolta, in Scala, è solo "evitata", dal momento che il compilatore, quando si tratta di "trait", fa un bel copia e incolla e non si preoccupa di controllare la coerenza - provate infatti ad esempio a far ereditare a Delfino sia il trait Mammifero che il trait Rettile:


class Delfino(aName: String) extends Animale with Mammifero with Rettile

giovedì 30 aprile 2009

Ajax su Https

Scenario: avete un'applicazione Ajax che funziona benissimo. Switchate il protocollo da Http a Https (SSL) e non funziona più.

La prima cosa che vi viene da pensare (come è venuta a me) è che Ajax - o meglio, l'oggetto XmlHttpRequest - non funziona su Https.

Ricerche e un po' di approfondimenti hanno risolto la situazione.

Intanto confermo che XmlHttpRequest (su qualsiasi browser, in particolare Firefox 3 e Internet Explorer 8) funziona su Https.

Il problema è che la pagina chiamante e lo script Javascript (e tutte le altre eventuali sorgenti che formano la pagina, ad esempio le immagini) devono assolutamente provenire da fonti sicure - cioè da fonti sotto Https.

Nel mio caso, infatti, le pagine venivano servite da una directory virtuale sotto Https, mentre gli script in Javascript erano serviti via Http normale. Se questo è il caso, XmlHttpRequest restituisce un errore di Security.

martedì 14 aprile 2009

Xorg.conf per Intel X3100

Un bug introdotto nella release 7.4 di Xorg (Linux) comporta un problema di visualizzazione nelle schede video Intel X3100 - ad esempio montate sui notebook Lenovo T60.

Questo bug fa sì che fallisca il riconoscimento dei driver corretti in automatico da parte di Xorg, cosicché occorre mettere mano direttamente alla configurazione nel file


/etc/X11/xorg.conf


Dopo una serie di tentativi e di studi, sono approdato alla configurazione ottimale, che riporto qua sotto e che si deve immettere andando a editare il file di cui sopra, ad esempio con:


sudo gedit /etc/X11/xorg.conf


Sostituendo interamente il suo contenuto con questo:


# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# Note that some configuration settings that could be done previously
# in this file, now are automatically configured by the server and settings
# here are ignored.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "Device"
Identifier "Configured Video Device"
Driver "intel"
Option "XaaNoPixmapCache"
Option "XAANoOffscreenPixmaps" "1"
Option "DRI" "true"
Option "AccelMethod" "XAA"
VideoRam 440320
Option "XvMCSurfaces" "6"
Option "May_Need_ForceBIOS" "1
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
EndSection

PS:
Oggi a colazione dicevo a Lucilla: "Vedi, figliola, non è vero che Linux è gratis! Il suo utilizzo impone che se uno trova la soluzione a un problema deve pubblicarla quanto prima su Internet. Fondamentalmente è questo il meccanismo che ha permesso all'Open Source di essere ciò che è oggi."

mercoledì 25 marzo 2009

Switch in Python

Com'è noto Python non supporta la sintassi "switch".

Invece che scrivere interminabili e poco leggibili catene di if/elif/else è possibile risolvere elegantemente la cosa con un dizionario.

Ecco un esempio:

        switch = {
'vigenere': Key(parameters),
'des': DESWrapper(password),
'3des': TripleDESWrapper(password)
}

if crypto_type in switch:
self.crypto = switch[crypto_type]
else:
pass
In questo esempio la funzione imposta l'oggetto self.crypto basandosi su una stringa di input crypto_type, che può assumere i seguenti valori:

  • vigenere
  • des
  • 3des

(come potete immaginare è un programma di crittografia). Il dizionario inizializza l'oggetto che, a seconda della stringa in input, può diventare di tipo "Key", "DesWrapper" o "TripleDesWrapper", passando al costruttore gli argomenti corretti.

Se la stringa crypto_type è trovata all'interno del dizionario switch l'oggetto viene inizializzato, altrimenti il programma passa oltre.

mercoledì 21 gennaio 2009

Nove regole di bellezza per il codice sorgente

Ho sempre amato un aspetto, nella programmazione dei computer, e cioè che le cose possono essere fatte in moltissimi modi diversi, e non c'è sostanzialmente un modo giusto e uno sbagliato di scrivere un programma per computer.

Tuttavia, esiste certamente un modo migliore ed uno peggiore per scrivere software. Ecco alcune norme basate sull'esperienza che vorrei condividere.

(In ciò che segue intendo per "codice" il "codice sorgente" di un programma per computer)

1. Il codice dovrebbe sempre tendere ad essere "bello"

2. Quasi mai la "bellezza" coincide con la "sinteticità", benché certamente un codice ridondante sia un codice brutto.

3. La "bellezza" di un codice è proporzionale alla sua "leggibilità"

4. Il codice "esplicito" è più bello di quello "implicito"

5. Le strutture "piatte" sono più belle delle strutture "innestate"

6. "Sparso" è più bello di "denso"

7. Un codice utile "in generale" (generico) è da preferire ad uno utile "in particolare" (ad hoc). La genericità è bella.

8. Non esiste un problema di programmazione che non sia risolubile attraverso la scomposizione in sotto-problemi. Perciò un codice bello è un codice "composto".

9. L'espressività di un linguaggio di programmazione si misura in quanti modi differenti è possibile implementare lo stesso algoritmo. Un linguaggio espressivo, solitamente è bello.