2011/12/7 Andrea Francia <span dir="ltr"><<a href="mailto:andrea@andreafrancia.it">andrea@andreafrancia.it</a>></span><br><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div>Per quanto mi riguarda cerco di usare quello che mi sembra risolvere meglio il problema e adoro imparare linguaggi nuovi.</div></div></blockquote><div><br></div><div>Eh, il problema e' che ci sono linguaggi che ti fanno crescere (e che poi magari hanno possibilità 0 di essere applicati nella tua realtà produttiva) e linguaggi che non lo fanno. In particolare PHP e' un linguaggio che non ti aggiunge *niente* (questo perche' e' molto povero di features). Presente Perlis? ;)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>Anch'io non capivo il senso dell'esistenza del '.' per concatenare le stringhe, poi me l'hanno spiegato.</div>

<div>PHP è stato fatto per scrivere veloci script web. Tutti i parametri che ti arrivano dal client web (per esempio come parametri della GET o della POST) sono stringhe.</div></div></blockquote><div><br></div><div>Fermo...</div>

<div><br></div><div>1. la quasi totalità dei programmi (in ogni linguaggio) per la maggior parte delle volte prendono l'input come stringhe di testo. In PHP ti arrivano dal client web come stringhe. In linguaggi meno web-oriented ti arrivano come input dall'utente (eventualmente da una unixiana concatenazione di stdout-stdin) o da file di testo. E sono testo. Sono "sempre" testo.</div>

<div><br></div><div>2. Il fatto che le stringhe si concatenino con il . viene dal Perl, mica da nient'altro. Non e' che la concatenazione di stringhe si faccia con . per altri motivi. E Perl era un linguaggio "nato" per manipolare files di testo e simili.</div>

<div><br></div><div>3. Il problema non e' che usi . per concatenare stringhe. Quella e' una scelta come un altra. In particolare, considerando che (strings, .) e' un monoide nemmeno abeliano a me non da particolarmente fastidio il fatto di *non* usare il simbolo +, che mi viene da associare ad una struttura di gruppo abeliano. Accetto la scelta di usare + anche per quello sulla base di non proliferare i simboli, sul fatto che probabilmente non fa troppo danno e fine della storia. </div>

<div><br></div><div>4. Il problema e' che le conversioni implicite sono *male*. E' una cosa nota: lo sbattimento (specie in un linguaggio dinamico) di avere conversioni esplicite e' relativamente piccolo. Diventa pesante solo se devi gestire tutti i tipi numerici, ma li le regole sono abbastanza ovvie e riesci a farle in modo non troppo non intuitivo -- e ribadisco, non farlo sarebbe peggio --.</div>

<div><br></div><div>Per il resto convertire una stringa in un numero prima di sommarla non mi riesce a sembrare un problema. E' anzi un'ottima idea, per come la vedo io.</div><div><br></div><div>Nota: le conversioni implicite danno problemi ovunque siano state applicate (a volte anche con i semplici numeri, quelle che avevo definito "buone" due paragrafi sopra).</div>

<div><br></div><div>Pensa al C++ e alla necessità di introdurre la keyword "explicit" perche' avere il costruttore di un parametro che ti auto-converte tutto portava problemi a non finire. Tanto che lo "standard" e' di dare explicit tutti i costruttori di un solo parametro per cui non si voglia *di certo* che la conversione sia implicita (e.g., e' comodo che char const* -> std::string funzioni, ma non e' una conversione logica).</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>Supponi di dover fare una pagina che stampa la somma di un numero, dovrebbe funzionare così:</div>

<div><br></div><div>     $ curl <a href="http://mioserver/somma.php?a=10&b=11" target="_blank">http://mioserver/somma.php?a=10&b=11</a></div>

<div>     21</div><div><br></div><div>Se hai un linguaggio come php puoi implementarla con (potrei sbagliare la sintassi):</div><div><br></div>print $_REQUEST['a'] +  $_REQUEST['b']<div><br></div><div>In questo modo non devi fare la conversione stringa->numero e non ottieni risultati scorretti come '1011'</div>

</div></blockquote><div><br></div><div>Pensa che io direi "non ottieni risultati *corretti* come 1011". Saro' old fashioned, ma se sommo due stringhe mi aspetto che queste vengano concatenate (se il linguaggio usa il + per la concatenazione) oppure mi dia errore se non lo fa.</div>

<div><br></div><div>Nota che il "problema" si risolve con due cast espliciti. </div><div><br></div><div>Se il "programmatore" non e' in grado di gestire la cosa (cioe' di capire che se gli arrivano due stringhe prima di sommarle deve convertirle) forse e' meglio che stia molto lontano da qualunque cosa che possa essere eseguita. ;)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">

<div>Non devi neanche gestire le eccezioni, è chiaro che è molto implicito e che sa un po' di quick and dirty, ma </div><div> 1) in alcuni casi non serve</div><div> 2) e se serve allora hai sbagliato linguaggio :-(</div>

</div></blockquote><div><br></div><div>Non gestire le eccezioni serve quando il linguaggio non gestisce le eccezioni. Allargando il discorso: "non gestire gli errori" lo puoi fare solo se hai un linguaggio con filosofie tipo "let it fail" (Erlang), e poi sono solo certe categorie di errori e, di fatto, e' come avere un certo sistema di gestione degli errori built-in nella piattaforma.</div>

<div><br></div><div>Per il resto, scusa, ma il "non gestire gli errori" non lo puoi fare. Ritornare silenziosamente un risultato sbagliato e' infame. Poi posso capire che non sai cosa fare con un errore (tutta la famosa discussione su quando e se catturare le eccezioni). Il problema e' che non devono andare sotto silenzio. A meno che non silenziate esplicitamente. E, aggiungo, se hai una buona ragione per farlo.</div>

<div><br></div><div>E no... non ho *sbagliato linguaggio*. E' il linguaggio ad essere sbagliato. Tout court.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div>Non voglio assolutamente discutere se questo sia un approccio valido o meno, è stata la scelta dei progettisti di PHP che può piacere o non piacere.</div></div></blockquote><div><br></div><div>

No. E' stata la scelta dei progettisti Perl. E nel contesto di Perl aveva anche un barlume di senso.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote">

<div><br></div></div></blockquote></div><div><br></div>-- <br> .<br>..: -enrico-<br>