Paolo Pialorsi

SOA, Workflow Foundation (WF), Windows Communication Foundation (WCF) e le Architetture Distribuite

News

Archives

TitleCase

So che è una sciocchezza, ma oggi stavo per farmelo da solo, ma come dice sempre Marco ;-) con .NET non bisogna mai iniziare a scrivere una classe o un metodo se non dopo aver verificato che effettivamente non esiste nel Framework. Ebbene ho scoperto un metodo, che quando serve è proprio comodo avere, che non conoscevo (e ce ne sono sicuramente tanti :-), sebbene usi il Framework .NET dal luglio 2000 quando era in Beta 1).

Oggi Avevo l'esigenza di convertire in TitleCase delle stringhe. In pratica mettere la prima lettera di ogni parola in maiuscolo e le altre in minuscolo.

Ecco fatto:

System.Globalization.TextInfo ti = new System.Globalization.CultureInfo("it-IT", false).TextInfo;
Console.WriteLine(ti.ToTitleCase("paOLo PIAlorsi"));

Il risultato sarà: Paolo Pialorsi

L'ho scritto per non scordarmelo e perché magari anche altri hanno avuto o avranno questa esigenza, quindi meglio trovare al volo come fare.
Posted: feb 28 2006, 02:50 by paolo | with 3 comment(s)
Filed under:

Comments

Marco Pappalepore said:

E' vero che bisogna usare l'esistente per non reinventare tutte le volte l'acqua calda, però non si dovrebbe abolire del tutto l'approccio creativo - e soprattutto autonomo - alla soluzione dei problemi.

Tirando le conseguenze del tuo ragionamento, non dovrei mai costruirmi un motore per il parsing dell'xml perchè ce n'è già uno in .NET. Ma se ci fossero algoritmi migliori di quello di Microsoft, chi penserebbe più a cercarne ?

Di questo passo non si rischia di dipendere troppo da una tecnologia ? In fondo però, la tecnologia è questo: è quello che non devi più fare da te, che è già pronto e da riutilizzare.
Risolverei la questione dicendo che io posso accettare di "abbandonarmi" a una tecnologia standard, a patto che mi permettano di esserne indipendente: devo sempre sapere quali algoritmi la implementano, così che se lo standard viene abbandonato o superato posso ricostruirmi tutto e non sono perduto con esso.

Questo è il modello open-source, che però non è quello per .NET. Se domani non ci sarà più .NET, che oggi uso già tantissimo, avrò ancora voglia di rimboccarmi le maniche e mettere una stringa in formato titolo "a mano"?

morale: w le librerie standard, ma vorrei potermi tenere una copia dei listati

ciao, Marco
# marzo 1, 2006 5:42

paolo said:

Ciao Marco,
con una battuta potrei risponderti che hai strumenti come Reflector, per verificare la bontà o meno degli algoritmi che utilizzi.

In generale, e seriamente, credo che più che avere i sorgenti di un prodotto o di un framework, sia importante avere garanzie di supporto e disponibilità dello stesso. Se lavori con un framework di migliaia di classi e centinaia di namespace, del quale hai sorgenti, credi davvero di poterlo riutilizzare anche se chi lo produce dovesse smettere di supportarlo?
Non è forse invece più importante utilizzare un framework che è regolamentato da standard (ISO e ECMA) e sapere che potenzialmente N realtà/aziende possono implementarlo con codice scritto in maniera differente, ma nel rispetto dello standard?

Ciao e grazie per il commento.

Paolo
# marzo 2, 2006 1:06

marco said:

La mia esperienza mi porta a dire che la qualità di un programma non la fanno le librerie usate ma il programmatore che lo scrive.
Qualsiasi programma (open-source, closed-source, whatever) diventa poi obsoleto nel giro di 10 anni, al punto che l'ambiente circostante ne obbliga la migrazione a piattaforme / interfacce utente / sistemi di comunicazione diversi.
Che poi la ricerca debba andare avanti, non ci sono dubbi, ma avere diecimila versioni della funzione che fa uppercase non credo che sia fondamentale, a meno che nel programma che scrivo le prestazioni o la capacità di maneggiare grandi volumi sia così critica da richiedermi uno studio ad-hoc. Di solito solo il 5% (forse il 10) della quantità di codice di un programma ha queste caratteristiche ed esigenze, il resto è "colla" che unisce sistemi e fa dialogare applicazioni e utenti.

Altro piccolo problema: è più probabile che tante persone conoscano una libreria standard piuttosto che un universo di funzioni personalizzate (e magari non così stabili e testate). Il ragionamento che sta dietro al mio suggerimento (che citava Paolo) è di non reinventare l'acqua calda, a meno che non ci si trovi in Siberia.

Marco
# marzo 2, 2006 9:12