domenica, gennaio 30, 2011

Tutti pazzi per.. la roccia!

...ho visto cose che voi "normali" non potreste immaginarvi: amici "in fiamme" ai bastioni delle placche di Oriana, pile frontali balenare nel buio...

Ma peeeeerché?

Perché chi si avvicina alla roccia impazzisce completamente? Questa è una bella domanda, notare che mentre ve la scrivo sono appeso allo stipite della porta dello studio.. sapete com'è.. bisogna tenersi in allenamento per "alzare il grado" (alcolico)!

Così, mentre pensavo ad una mia amica che invece gli stipiti delle porte li usa più "razionalmente".. per allenarsi con la progressione laterale, mi sono chiesto: "Cosa c'è di magico nell'arrampicata che fa impazzire tutti?".. saranno i posti splendidi, la sfida con sé stessi e la propria mente, voglia di sfidare le proprie paure mantenendo i nervi saldi anche quando l'ultimo rinvio sta a 8m di distanza, sarà la voglia di migliorarsi, di mostrare "cosa si sa fare"... o forse sarà la merenda valdostana ad attirarci tutti? (Non fatico a crederci.. ho già l'acquolina in bocca.. gnam gnam!!!)

Siamo a metà via, sono già le 17 (come al solito torneremo con le frontali accese), fa freddo, rischiamo di sfracellarci contro qualche cengia accuminata lasciando tra gli alpinisti l'unico tipo di traccia che NON vorremmo lasciare, il corpo deve arrivare sempre al limite delle sue capacità (vogliamo migliorare o no?), non abbiamo pranzato, ci mettiamo in situazioni pericolose di nostra volontà.. MA PEEEEEEEEEEEERCHE'?

Insisto.. la "merenda valdostana" è la risposta: una giornata intensa.. tutti assieme, affrontando delle piccole sfide.. in compagnia, ridendo, scherzando, sclerando, soffrendo.. eppur vivendo fino all'ultimo respiro ogni attimo tra amici in un posto splendido. Si respira serenità, amicizia, correttezza, profonda fiducia reciproca.. affidiamo le nostre vite l'un l'altro con fiducia...
Tienimi tesooo.. tienimiii.. posso? Mi lascio? Sicurooo? Guarda che sto per calarmi!
E dopo aver affrontato assieme mille e uno pericoli.. vinello rosso e fetta di salame alla rozza, all'alpina, perché non c'è nulla di meglio se non stare con degli amici, stanchi ma contenti, a condividere anche gli ultimi istanti (magari del tramonto) in mezzo ad una montagna, lontani da tutto...

...nel nostro mondo!

domenica, maggio 03, 2009

Disegno? Una questione di allenamento!

Saper disegnare sicuramente richiede capacità e talento.. io non penso di averli, però ho scoperto l'acqua calda: le capacità si costruiscono con l'allenamento, il talento può essere innato.. ma può anche essere costruito con l'esperienza.
Non ci credete? Bé non sono mai stato bravo a disegnare, nonostante io scolpissi e dipingessi con l'areografo (e qualche volta sulle magliette)...

E ADESSO???

Non so disegnare nemmeno ora, però comincio a stendere la grafite sulla carta in maniera quasi accettabile per un principiante. Un esempio? Eccolo:

mercoledì, marzo 04, 2009

E se dovessi programmare in C ANSI.. ma OO?

Oramai é sempre più raro trovarsi in questa situazione esistendo svariate soluzioni sia open che commerciali per lo sviluppo e la compilazione di codice C++ anche per architetture embedded. Ogni tanto però capita ancora di avere questa esigenza.. in quei casi?

La risposta viene da molto lontano nel tempo, molti di voi avranno sentito parlare del documento OOC, in cui si descrivono le tecniche per programmare in uno stile OO utilizzando l'ANSI C. Questo documento esiste da molti anni.. e quando lo scoprii (nel 2002 se non ricordo male) mi entusiasmò! In questi giorni però la stessa domanda mi é stata riproposta da un curioso molto in gamba.. e perché non fornirla a tutti sul blog? Ma di più.. dato che non ho mai nulla da fare (ironico ovviamente), perché non scrivere un esempio semplice semplice di tool costruito con le macro di preprocessore? E' un giocattolino senza esplicito supporto per l'ereditarietà, il polimorfismo e quant'altro.. però é simpatico e chi vuole può usarlo/estenderlo per gioco. Eccovelo in sole 50 righe di macro con un esempio semplice semplice.

Vediamo un esempio di dichiarazione di classe:

// La classe:
CLASS_BEGIN(CheckedInt)
ATTRIBUTE(CheckedInt,int,version);
METHOD(CheckedInt,void,setValue,unsigned long val);
METHOD(CheckedInt,unsigned long,getValue);
STATIC_METHOD(CheckedInt,unsigned long,max_val);
CLASS_END(CheckedInt)

// La struttura rappresentante un'istanza:
CLASS_INSTANCE_BEGIN(CheckedInt)
ATTRIBUTE(CheckedInt,unsigned long,value);
ATTRIBUTE(CheckedInt,unsigned long,not_value);
CLASS_INSTANCE_END(CheckedInt)

// Definizione di costruttore e distruttore:
CLASS_ALLOCATORS(CheckedInt,unsigned long val);
Lineare no? E l'implementazione? Eccola:

// Metodo d'istanza:
METHOD_IMPL_BEGIN(CheckedInt,void,setValue,unsigned long val)
this->value = val;
this->not_value = ~val;
METHOD_IMPL_END(CheckedInt)

// Caso statico:
STATIC_METHOD_IMPL_BEGIN(CheckedInt,unsigned long,max_val)
return 0xFFFFFFFE;
STATIC_METHOD_IMPL_END(CheckedInt)

//...

// Inizializzazione della struttura statica:
CLASS_INIT( CheckedInt,1,
CheckedInt_setValue,
CheckedInt_getValue,
CheckedInt_max_val);

// Costruttore:
CONSTRUCTOR_BEGIN(CheckedInt,unsigned long val)
this->value = val;
this->not_value = ~val;
CONSTRUCTOR_END(CheckedInt)

// Distruttore:
DESTRUCTOR_BEGIN(CheckedInt)
// Rilascio risorse.
DESTRUCTOR_END(CheckedInt)
Usiamo la nostra classe ora!

// Istanzio:
CheckedInt *ckdInt = CheckedInt_new(10);

// Chiamo un po:
printf("A checked value: %d\n", CALL(ckdInt,getValue));
CALL(ckdInt,setValue,42);
printf("A checked value: %d\n", CALL(ckdInt,getValue));

// Accedo agli attributi direttamente:
printf("I'm a bad boy! ;)\n");
ckdInt->not_value = 0;
printf("A checked value: %d\n", CALL(ckdInt,getValue));

// Uso il distruttore:
CheckedInt_free(ckdInt);
Ok, probabilmente molti di voi diranno "Tra C++, Java, C#, cicici e tututu sicuramente questo non mi serve!", sono perfettamente d'accordo con voi... ma ogni sfizio è sfizio!!! ;)

sabato, novembre 29, 2008

C#: Perdita di eleganza?

La prima volta che incontrai sulla mia strada il linguaggio C# fu nel 2003, era ancora un linguaggino molto molto MOLTO Java-style, quasi clone, con alcune features in più come boxing e unboxing, property, delegate, eventi e qualcosina d'altro.

Oggi, alla release 3.5 del .NET framework, assistiamo ad una evoluzione del linguaggio a dir poco sconvolgente! Lo dico in senso positivo da un certo punto di vista, in senso negativo da un altro:

Lati positivi dell'evoluzione del linguaggio C#
  1. Aggiunte features che permettono di modellare il software in maniera più flessibile, vedasi generics con constraints;
  2. Aggiunte features che semplificano la realizzazione di pattern comuni in maniera meno verbosa, vedasi iteratori e delegate.. anche se già dalla prima versione;
  3. Aggiunti strumenti per la cooperazione tra sviluppatori, vedasi classi e metodi parziali.
Lati negativi dell'evoluzione del linguaggio C#
  1. Metodi estesi, non hanno ancora un corrispettivo nell'esperienza comune (pattern che li vedano come strumento da utilizzare realmente);
  2. Metodi partial: si tratta in fondo di metodi virtual non puri ma senza codice (solo più efficienti.. ma i compilatori d'oggi risolvono anche quel problema!);
  3. generics: ancora problemi con i vincoli, da aggiungere features in questo caso:
    class Classe where T: operator > {...}
Insomma.. butto il sassolino: trovo che l'entropia di C# stia aumentando, portando ai problemi di utilizzo di ADA e Haskel! Voi che ne dite?

mercoledì, novembre 12, 2008

Nasce OpenTVF

Ragazzi.. nasce OGGI OpenTVF su sourceforge.. andate a dare un occhio! ;) Se qualcuno è interessato a collaborare con lo sviluppo di OpenTVF... é sempre ben accetto! :D

A BREVE... metterò su sourceforge anche altri progetti che per troppo tempo ho tenuto nel cassetto.. se poi qualche interessato mi darà una mano a renderli qualcosa di più appetibile per l'utente finale.. MEGLIO!

A prestisismo.. HAPPY CODING!!! ;)

mercoledì, novembre 05, 2008

Drago Magnus

Come avrete notato la DeA ha buttato fuori una quintalata di raccolte/enciclopedie/corsi/ecc ecc in fascicoli a partie da quest'estate; tra le tante ce n'é una intitolatea semplicemente "Draghi" che propone delle miniature, a detta loro da collezionare e basta.. ma io trovo che siano più divertenti da dipingere! Voi che ne dite? ;)

Vi prometto che la metterò anche su Picasa così che sia scaricabile in dimensioni originali.. solo che prima vorrei scattare qualche foto un po' più "ambientalizzata" e contestualizzata, con altre miniature (che ho già dipinto) in maniera da simulare una piccola bataglia "nani VS drago magnus".

P.S.: Chi di voi si ricorda chi è il drago magnus? Indizio: anche se nella foto non si vede, lo scudo l'ho dipinto di bianco con una croce rossa! ;)

mercoledì, ottobre 22, 2008

Diamante condannato

Diamante condannato


Una preziosa pietra,
rara tra coproliti,
risplende affannosa
nell’olimpo tra miti.

Non solo per natura
le doti son innate,
elogio di bravura
per sfide affrontate.

Diamante condannato,
solitario viaggio,
sogno decapitato
d’unione col raggio.

Onnipotente,
un dio “fato” eleva valorosi
che esternano spontaneamente.

martedì, settembre 16, 2008

J2EE SecurityService: potente ma...

...decisamente "entropico"!

Niente da dire su JAAS lato autenticazione, realizzato un po' sul modello di PAM (con cui tra l'altro può interagire), JAAS è decisamente costruito bene dal punto di vista dell'autenticazione.. per J2SE.. in J2EE le cose non vanno altrettanto bene dato che:
  1. ci si può autenticare in Ackerman(N,N) modi con N>3... il che tradotto da "modoDiDire" a "italiano standard" significa "troppi";
  2. l'autenticazione avvenuta in ognuno di questi modi porta a risultati diversi.. se almeno uno potesse scegliere una delle modalità di autenticazione qualunque (la più standard, la più comoda, ...) ottenendo lo stesso risultato... invece ci si può autenticare:
    • lato web-tier, utilizzando uno dei metodi vari (BASE,FORM,DIGEST,CUSTOM ecc) con identità salvata lato web-tier e propagata lato EJB;
    • direttamente tramite API dell'AS (come "com.sun.appserv.security.ProgrammaticLogin" in glassfish) saltando tutti i meccanismi di autenticazione standard.. e anche questo lato web e lato business con enormi differenze sul risultato;
    • utilizzando librerie che interagiscano con JAAS e con il SO, ad esempio per effettuare il login usando l'identità locale dell'utente (ad esempio un client di una applicazione EE potrebbe usare le credenziali di Windows o di PAM in Linux, Unix, MacOSX, "/.*[xX]/");
    • creando un proprio LoginModule e Realm (tanto per aggiungere entropia.. finiremo per confonderci con il "rumore di fondo"!!!)...
    • ...mi fermo ma potrei proseguire, sicuramente uno standard (anche de-facto) farebbe piacere.
  3. autenticazione=??? Ok, abbiamo controllato tutti i LoginModule di questa terra, username+password, impronte digitali, scansione retinica, statistiche di digitazione, impronta vocale, eco nel padiglione auricolare destro, ecc ecc... e mò? Salvataggio di Subject, Principal, Credentials... Tutto qui? E poi? Perché devo scrivere nel subject che sono "Gabriele Lombardi", creare un principal con dentro scritto "Gabirele Lombardi" e magari salvare le credenziali "Gabriele Lombardi"+"PasswdFuffa"???
Ma mica abbiamo finito.. eh no! Diamo un occhio lato autorizzazioni, da questo lato l'architettura è stra-fine: gestione di risorse, gestione di policy sulle risorse, di regole nelle policy, di permissions sulle risorse, di...
...insomma un casino!

Allora, dico io, va bene che bisogna poter fare mille cose.. che la sicurazza è una cosa, che bisogna essere generali e che usare i DesignPatterns aiuta a sviluppare software riutilizzabile e corretto... però a tutto c'é un limite! OPPURE...
Bene.. cari Sunnisti, esiste un simpatico BANALE pattern GOF di nome "Facade", lo usate sempre... ci sono package che fanno anche il caffé e nelle API pubbliche se ne vedono 4 classi/interfacce/annotazioni in croce! (Vedasi javax.persistence... fa l'impossibile.. ma "di nascosto")... usarlo anche per il SecurityService no eh? Magari usarlo UNA SOLA VOLTA ma bene.. creando un solo standard di accesso al servizio... non 27 modi diversi, non standard, vendor-dependent... e in generale diversi o peggio... quasi uguali ma con sfumature "cangianti"!!!

DETTO QUESTO...

Butto li una domanda-esempio: se volessi gestire dinamicamente utenti (e gruppi di utenti/gruppi organizzati in un DAG) nonché risorse (organizzate ad albero o DAG anche loro)... e poi volessi creare dei permessi che associno risorse e utilizzatori (utenti o gruppi) in maniera da poter risolvere i permessi sfruttando ereditarietà sia sulle risorse che sugli utenti/gruppi... come potrei fare? Ovviamente il tutto lo voglio fare dinamicamente.. non voglio uno staticissimo policy-file!

ESEMPIO:

RISORSE:
  • PhotoGallery
    • Gallery1
    • Gallery2
con permessi ordinati "edit">"comment"> "browse" (cioè che si implicano l'un l'altro).

UTENTI:
  • Users
    • Admin
    • Owner
    • KnownUser
PERMESSI:

  • Admin->Risorse: "*"
  • Owner->PhotoGallery: "*" (o "edit" dato che implica le altre)
  • KnownUser->Gallery1: "comment"
  • User->PhotoGallery: "browse"
Al che "Ciccio", associato al gruppo KnownUser, può vedere tutte le gallerie, ma può commentare solo Gallery1 e non può editare. "MasterOfPuppets" associato al gruppo Admin può fare tutto, mentre "QuiQuoQua", owner della galleria, può fare tutto.. ma solo sulla (sua) galleria.

Soluzione? Ovviamente costruibile a run-time.. cioè creando la struttura di risorse e utilizzatori a run-time aggiungendo tuple in una o più tabelle, creando le tuple di utenti e gruppi e creando le tuple per i permessi.

Vi prego... FLAMMATEMI questo post, così magari ci capisco un po' di più!!! ;)

lunedì, agosto 18, 2008

Diamo forma ai libri..!

Alla fine le poesie sono fatte per essere scritte.. e lette! Quindi eccovi la mia prima pubblicazione poetica ufficiale:

Deliranti sentieri...
...in versi sparsi.


Giusto per dare forma ai pensieri.. tipo forma di "parallelepipedo sfogliabile"! ;)

giovedì, agosto 07, 2008

Mutevole erotismo

Mutevole erotismo


Fantasia fervida,
ricerca di novità,
il docle piacere
d'un sogno proibito;
di tabù superati
è plasmata l'unione.

Fine delle idee,
nullo desiderio
d'arti spericolate;
sensibile profondo,
gustato a pieno,
l'amore passionale.

La sottomissione
all'amante deciso,
la prevaricazione
d'uno schiavo dolce,
scontro d'intensi sguardi:
si miscelan' i sensi.

Riscoprendoci dentro,
sbizzarrendoci fuori,
usando corpi nudi,
assaporando ogni
sfumatura d'anime,
siamo sempre più "NOI"!


Gabriele Lombardi

mercoledì, luglio 02, 2008

Sgretolandoti

Sgretolandoti


Mente d'instabile,
veloce deriva
d'una dolce pensatrice:
s'aggrovellano idee,
paure, proiezioni
d'un mondo che mai
fu meno reale.


Gabriele Lombardi

Fresche e lucenti... nell'oscurità

Fresche e lucenti... nell'oscurità


Perle trasparenti brillano:
da tiepidi raggi trafitte,
rotolano inermi lungo stami,
abbandonano i giovani germogli
per lanciarsi nell'abisso
ove non faranno ritorno.


Gabriele Lombardi

giovedì, maggio 15, 2008

Stagioni diverse

Stagioni diverse


Rotean ingranaggi
d'esseri mutevoli,
splendore rugginoso;
alternarsi frivoli
osservo personaggi.

Essendo incapaci
d'introspetta puntura,
dolore fastidioso
alimenta paura,
vegetano felici.

Rarament'intendendo,
ponendomi quesiti
vi osservo dubbioso:
contorto è l'animo,
lo sto somatizzando.

Gli umani son siti
d'intricati terrori:
chi diviene furioso,
chi rovina d'amori,
chi lavor'appassiti.

Io m'osservo: perdente
comprendo di non poter,
nell'animo fumoso,
duro nocciolo scorger:
sconfitta è sovente.


Gabriele Lombardi

mercoledì, maggio 14, 2008

Sambuco in fiore

Ragazzi, in questo periodo la natura si è svegliata e sembra impazzita. La camomilla romana ed i papaveri invadono i campi e le piante di sambuco riempiono l'aria di un profumo dolciastro. Maaa.. lo sapevate che:
  1. Il sambuco è una pianta commestibile, non tossica, i cui fiori hanno mille usi.
  2. In questo periodo i fiori aperti (e belli profumati) possono essere fritti in pastella (come i fiori di zucca) e comodamente mangiati utilizzando il picciolo del fiore come "manico".
  3. Per produrre un buon liquore al sambuco (non identico alla classica sambuca) è sufficiente raccogliere i fiori, separare i singoli fiorellini dal picciolo "sgrullando" il fiore su un giornale e tenerli in "infusione" per 40 giorni in alcool puro (in maniera tale che i fiori riempiano completamente il barattolo in cui sono posti); dopo questo periodo è sufficiente per ogni litro di alcool aromatizzato versare in una pentola un litro di acqua e 700g di zuccero e portare ad ebollizione (facendo sciogliere completamente lo zucchero con un cucchiaio), infine miscelare bene i due liquidi e lasciar raffreddare. La raccolta e separazione dei fiori dai piccioli è un'operazione velocissima (le piante di sambuco si trovano ovunque ed i fiori maturi si staccano subito), purtroppo bisogna aspettare 40 giorni (agitando di tanti in tanto il barattolo), però la preparazione finale del liquore con acqua e zucchero è un lavoro da 10 minuti!!!
  4. Sambuco è anche un comune di 84 abitanti in provincia di Cuneo ;)
  5. Il suo nome deriva dal greco, "sambuchè", una specie di flauto costruito rimuovendo il modollo morbido dai rami più grossi.
  6. E' una pianta emolliente e sudorifera, i fiori sono diaforetici, i frutti sono lassativi e la corteccia è diuretica. (ne ha una per ogni esigenza ;) Inoltre i fiori possono essere usati contro l'influenza tramite infusi e come astringenti per la pelle se se ne utilizza il decotto.
Tutto qui? No no: gli usi del sambuco sono 1000 e 1000.. ma non vi voglio togliere il piacere della scoperta, Google is your friend ;)

martedì, aprile 15, 2008

Notte perpetua

Belli guaglioni, eccovi un bel racconto da leggere d'un fiato e da commentare. Se fa schifo.. ditemelo pure, sono qui apposta per ricevere commenti di qualunque genere. Sicuramente non è un racconto "nella media". Ditemi che ne pensate, a presto.
Notte perpetua

mercoledì, marzo 26, 2008

OOP in VimScript

Vim è uno dei (due) editor di testo più potenti che esistano, e come il suo concorrente (Emacs) può essere programmato in (almeno) un linguaggio di scripting apposito: il VimScript (in Emacs si usa l'elisp). Il VimScript è un linguaggio molto potente, articolato, con strutture dati flessibili (simili alle strututre dati di Python), tra le quali i dizioniari. I dizioniari, utilizzati in maniera particolare, consentono la costruzione di funzioni in cui sia possibile accedere al loro contentuo, una sorta di self pointer. Buttiamo lì un'identità di cui discuterò con voi volentieri:
strutture+function_handler+self=object orientation
Vediamo come questa cosa possa essere vera in VimScript: per prima cosa vi esorto a scaricare questo archivio con all'interno del codice VimScript, fra cui quello che ho scritto per l'OOP. In secundis aprite ed osservate il file "OO.vim" presente nella cartella "VimPresentation\Automation\Scripting". In esso:
  • BaseClass: salva in una variabile globale la classe corrente, costruita come dizionario con l'entry speciale "__name" contenente i nomi delle classi da cui l'oggetto eredita (per ora solo la corrente) e l'array (ora vuoto) delle interfacce implementate. Successivamente lo restituisce.
  • Interface: nefinisce una struttura simile a quella di una classe ma senza array delle interfacce.
  • Hinerit: l'ereditatrietà è gestita all'interno del costruttore chiamando questa funzione, qui viene creata l'istanza della superclasse, viene poi aggiunto ai nomi delle classi da cui si eredita il nome della sottoclasse, sarà poi compito del costruttore terminare la propria opera aggingendo nuovi attributi e svolgendo altri compiti di inizializzazione.
  • Virtual: i metodi virtuali non sono altro che metodi che vengono (nella sottoclasse, non nella superclasse come in C++) salvati all'interno della strututra d'istanza sotto nuovo nome tipo "superclasse_metodo" e che quindi vengono sostituiti nella sottoclasse.
  • PureVirtual: un metodo virtuale puro invece è un metodo che non è ancora stato implementato, se ne genera quindi una versione dummy ( che genera solo un'eccezione) e si utilizza la stessa tecnica dei metodi virtuali.
  • Implements: l'implementazione delle interfacce significa due cose:
    1. l'interfaccia (il suo nome) deve figurare tra le interfacce implementate,
    2. tutti i metodi virtuali puri presenti nell'interfaccia devono essere in quelche modo "importati" all'interno della classe corrente (starà poi al programmatore implementarli).
  • Isa: usando i nomi da dizionario si può sapere se una istanza è (da qualche parte nell'albero d'ereditarietà) istanza di una determinata classe.
  • IsImplemented: in modo analogo si può controllare se un istanza implementa una determinata interfaccia.
  • Import: un po' di comodità non guasta! ;)
Detto questo, sperando che abbiate contemporaneamente visionato il (semplicissimo) codice in VimScript che definisce queste funzioni, vediamo come utilizzarle per definire una classe, il classico contatore. Riporto e commento il file "Counter.vim":
let s:_default = 42
All'interno di uno script le variabili nello scope s: sono locali allo script stesso, per una classe questo significa avere a disposizione uno strumento per gli attributi statici.
function! Counter(...)
...
endfunction
Al solito definiamo una classe come funzione con funzioni innestate, la funzione di suo farà da costruttore. In fondo si può trovare il codice:
function! Counter_compare(a,b)
" Contronto actual:
return a:a._actual>a:b._actual
endfunction
che definisce una funzione friend. Il costruttore svolge le seguenti azioni:
if a:0<1
let initial = s:_default
else
let initial = a:1
end
let counter = BaseClass('Counter') | Implements ICounter
call extend(counter,{'_actual': initial})
che rappresentano:
  1. inizializzazione dell'attributo "initial" come variabile (per ora) locale,
  2. creazione dell'istanza con implementazione dell'interfaccia ICounter,
  3. agginta dell'attributo privato "initial".
Vedremo dopo come è stata definita l'interfaccia, ovviamente la sintassi deriva dal fatto che è stato creato un comando apposito per la definizione delle interfacce implementate, che richiama la funzione omonima.
A questo punto vengono aggiunti i metodi (eventualmente dichiarati virtuali se devono sovrascrivere i metodi di una superclasse o di un'interfaccia):
Virtual actual
function! counter.actual() dict
return self._actual
endfunction
E la classe è pronta! ;) Si osservi che i metodi vengono dichiarati con la speciale sintassi:
funciton! struttura.nome(...) dict
...
endfunction
dove la parola chiave "dict" assicura che all'interno del metodo si possa fare riferimento al dizionario "counter" con la parola chiave self. Si noti anche che il nome della funzione inizia con il nome dell'istanza che si sta costruento e che verrà restituita al termine del costruttore, infatti si sta semplicemente dichiarando un funciotn_handler di nome (in questo esempio) "actual" all'interno del dizionario "counter" richiedendo di generare il riferimento locale "self" con la parola chiave "dict".
Nel file "StepCounter.vim" si può osservare che l'ereditarietà è ottenuta semplicemente sostituendo la chiamata a "BaseClass" con la chiamata a "Hinerit" passando anche il nome della superclasse e la lista degli argomenti.
Con la definizione dei comandi si è resa semplicissima la dichiarazione delle interfacce:
fun! ICounter()
let counter = Interface('ICounter')
Abstract actual next prev set
return counter
endfun

Infatti:
  1. Si crea l'interfaccia in una fuzione "costruttore",
  2. si crea "l'istanza" con "Interface",
  3. si creano i metodi virtuali puri col comando "Abstract",
  4. si restituisce l'interfaccia.

OO in Matlab: Single inheritance

Belli guaglioni, ricordate questo post rtelativo alla programmazione OO in Matlab? Bè ogni tanto per sfizio mi diletto a giocherellare con la metaprogrammazione e ho da proporvi un paio di chicche, una (banale) in matlab e una più interessante in VimScript (prossimo post).
Iniziamo pensare alla tecnica proposta per programmare OO in Matlab, abbiamo compreso come ottenere molte features, non abbiamo ottenuto però l'ereditarietà. Per aggiungere l'ereditarietà vogliamo tenere d'occhio i seguenti aspetti:
  • Overriding: vogliamo poter "sovrascrivere" i metodi della superclasse con le nostre nuove versioni senza perdere però la possibilità di accedere esplicitamente alle versioni della superclasse.
  • Accessors: non abbiamo descritto in maniera molto dettagliata come poter realizzare dei metodi accessori al meglio della comodità d'utilizzo, l'idea è quella di ottenere una sorta di property come in C#, per intenderci.
  • Protected access: nell'antico post sulla OOP in Matlab abbiamo descritto in maniera precisa come ottenere accesso pubblico e privato ai metodi, come costruire funzioni private accessorie non legate agli oggetti, come memorizzare gli attributi come privati ma non come pubblici (cosa che non faremo, usando invece i metodi accessori). Resta però da efinire come ottenere un livello protetto di accesso ai metodi o attributi. Si cominci a considerare il fatto che se si ottiene l'accesso protetto ai metodi si può sfruttare quello per avere accesso protetto verso gli attributi semplicemente con degli accessori protetti. Per ora però purtroppo non siamo in grado di creare metodi ad accesso protetto, quindi ci limitiamo ad utilizzare la tecnica delle property.
Dopo tutta sta pizza passiamo al codice: vogliamo creare la classe stepCouter sottoclasse di counter, in essa dovremo sfruttare il valore attuale del contatore per poterlo leggere, modificare e reimpostare; per questo motivo creiamo il seguente metodo accessorio nel contatore:
% The actual value accessor:
function ao = Actual(ai)
% Getting the actual value:
if nargin>0; start=ai; end

% Setting the output:
if nargout>0; ao=start; end
end
Collegheremo questo metodo all'oggetto salvando il function_handler con il nome "actual" all'interno dell'istanza restituita:
% Returning the counter: this is the public methods' set exported.
c = struct('next',@Next,'prev',@Prev, ...
'reset',@Reset,'actual',@Actual);
Fatto questo abbiamo la possibilità, nella sottoclasse, di istanziare il contatore e aggiungervi dei metodi che, sfruttando la property 'actual', possano modificare anche l'istanza della superclasse.
Si noti che la superclasse e la sottoclasse avranno collegati a sé due workspace differenti con all'interno i loro rispettivi attributi privati; questo significa che con questa tecnica comunque ogni classe genera istanza che hanno il proprio workspace separato da tutti gli altri, senza possibilità di interferenze. Ecco il codice:

function c = stepCounter(start,step)
% STEPCOUNTER Generates a new counter that uses a step.
%
% Here the single hineritance is obtained by generating an object of the
% superclass and then joining the method calls, notice that the mantained
% workspaces are distinguished so there are difficulties in the private
% attributes access (there is no protected access, only public or private);
% so an accessor in the class "counter" must be added (in this case
% "actual"), this allows to have the actual attribute to be public.

% =========================================================================
% Creating the object:
% =========================================================================

% Using the superclass' constructor:
c = counter(start);
clear start;

% Adding local methods:
c.step = @Step;
% Saving the old method so that can be explicitly called if required:
c.counter.next = c.next;
c.next = @Next;
% Same for the prev:
c.counter.prev = c.prev;
c.prev = @Prev;

% =========================================================================
% The public methods body.
% =========================================================================
% The next integer function:
function n = Next
% Increment:
n = c.actual(c.actual() + step);
end
% The prev integer function:
function n = Prev
% Decrement:
n = c.actual(c.actual() - step);
end
% Setting and getting the step value:
function so = Step(si)
% Getting the actual value:
if nargin>0; step=si; end

% Setting the output:
if nargout>0; so=step; end
end
% =========================================================================
% Private methods are simple functions and can be defined here.
% =========================================================================
end

% =========================================================================
% Support functions that are not methods (no access to attributes) are
% defined here.
% =========================================================================
Quindi in questa sottoclasse "step" è un attributo locale privato, ed è l'unico presente nel workspace della sottoclase "stepCounter", il parametro "start" del costruttore viene rimosso una volta utilizzato perché dopo la chiamata al costruttore della superclasse non serve più (è stato memorizzato nel workspace della superclasse) e se non eliminato rimarrebbe nel workspace privato della sottoclasse "stepCounter" occupando spazio inutile e potenzialmente dando la possibilità di scrivere codice errato e confuso. Per "step" si è creata una property, i metodi "next" e "prev" sono stati sostituiti e le vecchie versioni sono state salvate nella struttura stessa in una sottostruttura con il nome della superclasse. Ora è possibile scrivere codice come il seguente:
c1 = counter(10);
c2 = stepCounter(10,10);
c1.next()
c2.next() % Uso la versione "overridata":
s=c2.step %ottengo lo step:
c2.step(20); % Imposto lo step:
c2.counter.next(); % Uso la versione originale:

mercoledì, febbraio 13, 2008

Commenti in C++

I linguaggi C/C++/Java/ecc (anche se non nello standard C99) prevedono l'utilizzo di due diversi tipi commenti:

// Commento su una riga (one-line comment)
/*
Commento di un intervallo di testo (range comment)
*/

Inoltre non prevedono comment nesting (annidamento dei commenti), quindi suddividono l'input in token "//", "/*" e "*/" dipendentemente dal contesto (di commento). Questo unito all'utilizzo del carattere "/" condiviso tra i due tipi di commento permette di "giocare" per ottenere risultati interessanti e utili.. quando si dice giocare con poco per ottenere molto! ;)

Date un occhio a questi esempi e se vi va lasciatemi un commento (al blog, non in C++ ;)

martedì, gennaio 29, 2008

Buio illuminante

Buio illuminante


Luce diffusa, radente, coglie
ogne anfratto dell’anima pia,
occultando le ombre minacciose.
In agguato pazientano tenebre,
liberatrici di spettri antichi,
nulla può impedirne il ritorno.

Miope dell’antica identità,
non comprendo il profondo dolore;
erroneamente intendo segni
mostratimi con gesti inattesi.
Nel buio profondo ora brancolo
fiutando intesa per dar appoggio.

Giornate luminose rendon ciechi,
sovente di più svela oscurità,
chiarore perpetuo, s’apprezza poco.
Nell’ombra, un sol raggio di speranza
pare illuminar l’intera vita,
vien ben percepito con ogne senso.

Dovrebbe serenità
pervadere le menti
d’accecati dispersi:
vedranno più di prima.

Non capendo,
percepisco.


Gabriele Lombardi

venerdì, novembre 23, 2007

Goccia

Goccia


Goccia mi s'è posata
d'improvviso sul volto:
pioggia lieve, trasporta;
saran d'uno stolto,
ma l'antichi riporta
mente d'era passata.

Frenetico appare
seguirsi d'adulteri
giorni non penetranti:
son gl'intensi valori,
e non i fuorvianti,
cui voglio l'sapore!

Aspirandot'appieno
gusto l'vero valore
ch'amalgama serena
coscienza d'amore;
sublima l'anatema,
errar pare ameno.

Son gli alti e bassi
che compongono succo
di esistenza, piatto
appare il rintocco
d'esistere coatto:
sovente siam percossi!

Usma essenza densa
di quanto già possiedi;
aspira la fragranza
di antichi rimedi
qual vera sostanza:
palpito non pensa.


Gabriele Lombardi