Undolog.com

Scrissi un articolo simile per ActionScript tempo fa: Actionscript 3.0: public, protected, private e internal. Rileggendolo mi sono accorto di due cose: la prima è stata l’estrema somiglianza con Objective-C, anche se quest’ultimo non contempla internal.

Continua...

Chi ha iniziato a sviluppare codice con linguaggi di scripting come Javascript o lo stesso Actionscript, potrebbe non conoscere affatto il concetto di tipo dato. Con alcuni linguaggi ad alto livello, infatti, si è abituati – nella migliore delle ipotesi – a dichiarare le variabili senza assegnargli un tipo dato specifico, senza contare quei linguaggi che non richiedono nessuna dichiarazione (come ad esempio il PHP – non nella versione strict 5).

Continua...

La funzione wp_parse_args() (come molte altre non documentata) elabora una stringa nel formato:

Continua...

Riprendiamo il nostro codice di esempio del TicTacToe (che trovate per intero su Google Code) e iniziamo ad analizzarlo in dettaglio.

Importare le definizioni

Con Actionscript 3.0 è stato fatto un grande lavoro di pulizia e sistemazione nell’alberatura delle classi (contenute nei pacchetti, package) utilizzate durante lo sviluppo. In altri linguaggi di programmazione, come il C ad esempio, quando si desidera utilizzare una funzionalità bisogna esplicitamente “importarla” nel codice. Questa operazione di “importazione” è necessaria per permettere al compilatore di avere tutti i codici e le definizioni legate alla funzionalità che vogliamo usare. In Actionscript 3.0, tuttavia, l’istruzione import non va confusa con l’equivalente C/C++ #include; Actionscript 3.0 mette a disposizione l’istruzione include che è identica all’#include del C/C++. Quest’ultima, infatti, “include” effettivamente del codice che, se usato o meno, viene compilato nell’eseguibile finale. L’istruzione import è di più alto livello e risulta più “intelligente” in fase di compilazione. Essa serve principalemente per accedere alle classi senza doverne specificare il nome completo. In alre parole invece di usare forme del tipo:

Continua...

Sembra ovvio, ma ad alcuni sfugge la sottile differenza tra costanti e variabili in un linguaggio di programmazione. Le costanti, dal nome stesso, non cambiano il loro valore durante il ciclo di un programma, mentre le variabili possono farlo! Tuttavia, spesso, capita di usare variabili al posto di costanti senza rendersene conto, anche perchè questo non impatta la logica di una applicazione. Nonostante questo, la differenza tra costanti e variabili c’è ed emerge tutta nel momento della compilazione, dove la costante gioca un ruole sicuramente più performante.

Chi viene dalla programmazione Assembly o C conosce bene la differenza tra costanti e variabili, soprattutto perchè, sia in Assembly che in C, le costanti rivestono un ruolo più da MACRO. Per MACRO indendo una “parte di codice” che viene etichettata e sostituita all’interno del codice nel momento della compilazione. Il compilatore, per farla breve, esegue una sorta di find..replace (trova e sostituitsci) nel codice ogni volta che incontra una costante.

Immaginiamo di scrivere in C la seguente semplice porzione di codice:

Sia a che b sono indicate come variabili in questo caso. In C, infatti, le costanti si definiscono con la keyword #define. Notiamo subito che sia a che b sono state definite come int. Già qui si può operare una prima ottimizzazione. Se sappiamo che la nostra variabile a non supererà mai un determinato valore, è bene dichiararla in modo appropriato e non usare tipi dati a caso. Alcuni sviluppatori non si preoccupano affatto di dichiarare correttamente i tipi, pensando che questo non influisca sulle performace! Sbagliato! In alternativa è accettabile che la prima stesura del codice non implichi questo livello di dettaglio. È comunque buona regola, durante il processo di sviluppo, rivedere il codice e verificare i tipi dati.
Comunque sia, in un Assembly della famiglia Motorola, ad esempio, come il mitico 68000, il nostro codice verebbe compilato (senza ottimizzazioni) in una specie di:

oppure:

Il compilatore, per quanto intelligente, fatica nelle ottimizzazioni, quindi scrivere il codice con le giuste keyword può solo aiutarlo a migliorare l’output compilato. Nel nostro caso se il valore 5 è una costante non è conveniente usare una variabile intera, in quanto il compilatore, giustamente, considerando la variabile variabile, appunto, predisponde un intero per contenere il semplice valore di 5; che in binario è 101, cioè occupa 3 semplici bit (caso mai int è un 32bit o peggio un 53bit a doppia precisione a virgola mobile!!). Se avessimo scritto il codice in questo modo:

Il compilatore avrebbe saputo sin dall’inizio che MIA_COSTANTE, essendo costante, non muterà valore e quindi posso riservare meno spazio per trattarla. Nella pratica il codice Assembly diverebbe:

Quest’ultimo codice è estremamente più rapido e occupa meno byte. Quello che bisogna tenere a mente è che quando si dichiara una variabile l’ambiente si predispone per trattarla come tale, anche se i compilatori di oggi riescono a fare miracoli, eseguendo una serie di passaggi nel codice prima di compilare (alcuni compilatori, addirittura, eseguono una specie di simulazione del programma per ottimizzare al massimo la compilazione in codice macchina).

Una buona regola, quindi, è quella di dichiarare il giusto tipo per le nostre variabili, se tali sono. In alternativa usare le costanti, soprattutto se il linguaggio di programmazione che stiamo usando le prevede (come nel caso del nuovo Flash CS3).

Continua...