as3 reflection

[Piergiorgio Niero]

Recentemente ho sperimentato con somma frustrazione la reflection in as3.

in soldoni la situazione che ho sperimentato è questa:

se si vuole fare una factory per l'istanziazione di oggetti con numero variabile di parametri al costruttore è IMPOSSIBILE farlo in modo dinamico.

mi spiego meglio:

mettiamo il caso di avere una factory statica che istanzia oggetti passando una Class e un array di parametri, qualcosa con una signature tipo MyFactory.createInstance(myClass:Class,params:Array):Object

l'implementazione del metodo createInstance dovrebbe (a logica) essere qualcosa tipo

return new myClass(params);

PERO' myClass dovrebbe ricevere in input un array, cosa che non posso sapere in anticipo a meno che la mia factory non possa istanziare solo classi con queste caratteristiche (tagliando fuori tutto il resto, il che è a mio avviso inaccettabile).

ho pensato a "... (rest)", ma anche lui è un array, quindi ciccia..

alla fine sono giunto ad una conclusione SPORCHISSIMA ma che fa il suo sporco lavoro: uno switch con 10 casi (è difficile trovare una funzione con + di 10 argomenti al costruttore) a seconda di quanti item sono presenti nell'array di parametri.

ho avuto anche la certezza dell'unicità della soluzione perchè framework come spring per actionscript fanno esattamente così...-.-'

sinceramente a me fa parecchio schifo questa lacuna, ma non so come funzioni negli altri linguaggi (forse massimo e luca possono dire qualcosa su come funziona su coldfusion)....

morale: ho scritto un post con l'esperienza frustrantissima vissuta e ho aperto una feature request sul jira di adobe, rispettivamente http://www.flashfuck.it/2009/12/02/as3-reflection-crapyness/ e https://bugs.adobe.com/jira/browse/FP-3364

voi avete avuto esperienze in merito?

Piergiorgio Niero 

TheFlashMind AUG - Italy 

[mas...@massimocorner.com]

> framework come spring per actionscript fanno esattamente cos�...-.-'

> sinceramente a me fa parecchio schifo questa lacuna, ma non so come
> funzioni negli altri linguaggi (forse massimo e luca possono dire
> qualcosa su come funziona su coldfusion)....

Paghi il prezzo dell'avere un linguaggio rigido e strongly typed.

Con CFML il problema non si pone, potresti:

- Passare l'intero array di parametri al costruttore

- Iterare sull'array e passare i parametri al costruttore per posizione

- Passare i parametri alla factory come hashmap (una serie di coppie
nome/valore, structure in CFML, dictionary in Python etc) e passare i
parametri per nome invece che per posizione, visto che in CFML �
consentito passarli in entrambi i modi

Piu' in generale in linguaggi meno tipizzati gestire signature con
parametri opzionali e/o valori di default tende ad essere piu' facile

Massimo

[Piergiorgio Niero]

La cosa ridicola è che in AS3 la classe Function (da cui tutte le funzioni ereditano) ha una funzione "apply(params:Array)" che non fa altro che chiamare la funzione con un determinato set di parametri... il costruttore di una classe è una funzione, ma apply non è applicabile....

:\

sono fortemente tentato di tirare su un'iniziativa tipo il "make some noise" di andrè michelle, ma non so quanta gente usi la reflection...

On 07/dic/09, at 15:02, mas...@massimocorner.com wrote:

framework come spring per actionscript fanno esattamente così...-.-'

sinceramente a me fa parecchio schifo questa lacuna, ma non so come

funzioni negli altri linguaggi (forse massimo e luca possono dire

qualcosa su come funziona su coldfusion)....

Paghi il prezzo dell'avere un linguaggio rigido e strongly typed.

Con CFML il problema non si pone, potresti:

- Passare l'intero array di parametri al costruttore

- Iterare sull'array e passare i parametri al costruttore per posizione

- Passare i parametri alla factory come hashmap (una serie di coppie
nome/valore, structure in CFML, dictionary in Python etc) e passare i

parametri per nome invece che per posizione, visto che in CFML è

consentito passarli in entrambi i modi

Piu' in generale in linguaggi meno tipizzati gestire signature con
parametri opzionali e/o valori di default tende ad essere piu' facile

Massimo

[Bianchi Luca]

AS3 è tipizzato per modo di dire.. :-)

In pratica, non sei obbligato a specificare il tipo di un dato ed ottieni un warning in compilazione.

Inoltre puoi specificare un tipo di dato che sarà definito a runtime come *.
Con una cosa del tipo
public miaClasse(params:*)
in questo modo puoi passare il parametro che vuoi alla tua classe

La rogna sta secondo me nel fatto che non hai alcun controllo su quello che passi. Può essere di tutto e non necessariamente qualcosa che la tua classe sa gestire.
Il problema comunque sta secondo me nel fatto che AS3 vuole essere un linguaggio OO, senza ancora esserlo del tutto, quindi alcune cose ti tornano comode, altre invece le trovo davvero lacunose.

Negli ultimi mesi ho lavorato parecchio in Java e solo da un paio di settimane mi sono ritrovato su AS3. E devo dire che tutte queste limitazioni mi stanno infastidendo molto più che un tempo.

Luca



On 07/dic/2009, at 15.02, mas...@massimocorner.com wrote:

>> framework come spring per actionscript fanno esattamente così...-.-'

>> sinceramente a me fa parecchio schifo questa lacuna, ma non so come
>> funzioni negli altri linguaggi (forse massimo e luca possono dire
>> qualcosa su come funziona su coldfusion)....
>
> Paghi il prezzo dell'avere un linguaggio rigido e strongly typed.
>
> Con CFML il problema non si pone, potresti:
>
> - Passare l'intero array di parametri al costruttore
>
> - Iterare sull'array e passare i parametri al costruttore per posizione
>
> - Passare i parametri alla factory come hashmap (una serie di coppie
> nome/valore, structure in CFML, dictionary in Python etc) e passare i

> parametri per nome invece che per posizione, visto che in CFML è

> consentito passarli in entrambi i modi
>
> Piu' in generale in linguaggi meno tipizzati gestire signature con
> parametri opzionali e/o valori di default tende ad essere piu' facile
>
> Massimo

Luca Bianchi
mobile: +39 328 6867731
mail: bianch...@gmail.com

[mas...@massimocorner.com]

> La cosa ridicola � che in AS3 la classe Function (da cui tutte le

> funzioni ereditano) ha una funzione "apply(params:Array)" che non fa
> altro che chiamare la funzione con un determinato set di parametri...

> il costruttore di una classe � una funzione, ma apply non �
> applicabile....

Mi sembra un retaggio di JavaScript/AS 1. Ma un retaggio di quelli buoni,
apply() e call() in JavaScript mettono a disposizione una enorme
flessibilit�, non solo perch� in JavaScript i parametri non possono essere
passati per nome (solo per posizione), ma anche perch� con apply() si puo'
eseguire una funzione in un contesto arbitrario.

Magari nello sforzo di somigliare a Java si sono perse per strada alcune
cose interessanti...

Massimo

[Bianchi Luca]

Segnami tra i partecipanti. :-)
Se vieni da Java sei molto abituato ad usare la reflection, se vieni da altri linguaggi che non l'hanno ne fai anche a meno.
Secondo me il discriminante è quello che stai facendo. Mi spiego meglio: se stai scrivendo un'applicazione puoi anche fregartene in buona misura. Se invece stai scrivendo un framework, diventa più difficile proprio perchè hai esigenze di generalizzazione.

On 07/dic/2009, at 15.13, Piergiorgio Niero wrote:

> La cosa ridicola è che in AS3 la classe Function (da cui tutte le funzioni ereditano) ha una funzione "apply(params:Array)" che non fa altro che chiamare la funzione con un determinato set di parametri... il costruttore di una classe è una funzione, ma apply non è applicabile....
> :\
> sono fortemente tentato di tirare su un'iniziativa tipo il "make some noise" di andrè michelle, ma non so quanta gente usi la reflection...

[mas...@massimocorner.com]

> AS3 � tipizzato per modo di dire.. :-)

Tipizzati lo sono quasi tutti i linguaggi, compresi CFML, JavaScript e
PHP, alcuni lo sono meno (loosly) altri di piu' (strongly). Il range �
ampio :-)

Massimo

[Bianchi Luca]

Si, mi sono perso un fortemente... :-P
intendevo dire che AS3 è fortemente tipizzato per modo di dire.. nel senso che puoi anche non tipizzare ed il compilatore ti risponde solo con un simpatico warning, quindi se facciamo una scala con in ordine di "è più fortemente tipizzato" direi che AS3 è più fortemente tipizzato di CFML e (molto) meno di Java

On 07/dic/2009, at 15.23, mas...@massimocorner.com wrote:

>> AS3 è tipizzato per modo di dire.. :-)

>
> Tipizzati lo sono quasi tutti i linguaggi, compresi CFML, JavaScript e

> PHP, alcuni lo sono meno (loosly) altri di piu' (strongly). Il range è
> ampio :-)

[mas...@massimocorner.com]

> Si, mi sono perso un fortemente... :-P

> intendevo dire che AS3 � fortemente tipizzato per modo di dire.. nel senso

> che puoi anche non tipizzare ed il compilatore ti risponde solo con un
> simpatico warning

Non lo sapevo, pensavo si rifiutasse di compilare...

Massimo

[Bianchi Luca]

A quanto pare puoi anche fare una cosa del tipo

var pippo;

pippo = "mia Stringa";

var pluto:ArrayCollection = new ArrayCollection();

pippo = pluto;

mentre se cerchi di fare

var topolino:Number = 3;

pluto = topolino;

si incacchia e non compila.

Cmq, sarà una reminescenza da "javaro", ma non ho un grande amore per la tipizzazione debole.. 

Ho fatto poca roba in JS, ma mi sono scontrato con la necessità di sottrarre o sommare 0 ad una variabile, per farla considerare un numero. Lo trovo davvero assurdo.

Differente discorso con CF, dove di fatto sotto c'è Java che è fortemente tipizzato, quindi la tipizzazione debole è un'astrazione, ma l'interprete fa una type inference più che solida.

Per quanto AS3 quasi tutto il mio codice ha variabili fortemente tipizzate, quando proprio devo evitare, uso un tipo generico * (ok ok, in quest'ultimo caso non è molto utile, ma i 3 caratteri in più battuti risolvono il suddetto warning)

Luca

On 07/dic/2009, at 15.34, mas...@massimocorner.com wrote:

Si, mi sono perso un fortemente... :-P

intendevo dire che AS3 è fortemente tipizzato per modo di dire.. nel senso

che puoi anche non tipizzare ed il compilatore ti risponde solo con un

simpatico warning

Non lo sapevo, pensavo si rifiutasse di compilare...

Massimo

[mas...@massimocorner.com]

> Ho fatto poca roba in JS, ma mi sono scontrato con la necessit� di

> sottrarre o sommare 0 ad una variabile, per farla considerare un numero.
> Lo trovo davvero assurdo.

parseInt() o parseFloat(), sottrarre o sommare 0 funziona, ma � un hack,
oltretutto non necessario.

Massimo

[Piergiorgio Niero]

Segnato! :)

prima però vorrei capire come ragiona java, python, c++, c# etc in merito..

così posso confrontare i vari approcci e vedere se effettivamente in altri linguaggi si può fare oppure ci sono solo workaround (anche se massimo ha già detto che in cf e python la cosa è fattibile, quindi c'è poco da girarci intorno ...)

a breve avrete notizie :)

[mas...@massimocorner.com]

> massimo ha gi� detto che in cf e python la cosa � fattibile

Ho nominato Python solo per spiegare meglio cosa sia una "structure" in CFML.
Non conosco Python, dunque non posso essere sicuro si possa fare. Suppongo
di si. Mi aspetto sia possibile in tutti i linguaggi poco tipizzati.

Massimo

[Piergiorgio Niero]

peter elst ha fatto un test della web experience con ipad\iphone\isalcazzo

davvero meritevole :)

in pratica ha dimostrato come i plugin siano essenziali per avere una navigazione degna di essere chiamata tale

http://www.youtube.com/watch?v=dYxJf-7-Mus

[Piergiorgio Niero]

Continuo il post con qualche news :)

ho avuto l'occasione di approfondire su spring as3 e ho trovato alcuni limiti al framework, ma anche un team di sviluppo piuttosto reattivo.

Un limite in cui mi sono imbattuto è stato creare degli oggetti a runtime (non definiti nel contesto) non visuali (quindi non figli di DisplayObject) con proprietà marcate come [Autowired] popolate con valori di oggetti definiti nel contesto.

Il framework infatti prevede questa opzione solo per oggetti visuali cablando le proprietà autowired mettendosi in ascolto su Event.ADDED.

Ho creato una classe che permette di aggirare il problema (solo su architettura puremvc) e la potete trovare qui http://www.flashfuck.it/2010/01/21/spring-actionscript-autowire-objects-not-defined-in-context/

Estendendo questa classe è possibile creare oggetti che si "autowirano" appena istanziati,

quindi se la propria classe MyClass estende AutowiringObjectBase tutte le proprietà di MyClass marcate come [Autowired] andranno ad essere cablate da contesto.

Ho postato questa soluzione nel gruppo di spring as3, e dalla prossima versione ci sarà un metodo nuovo a risolvere il problema e che (al contrario della mia soluzione) disaccoppia la classe dalla logica del framework (in pratica non si dovrà estendere un bel niente). il metodo nuovo è applicationContext.createInstance(myclass,arguments) ed è già committato sull'svn del progetto.

[pix303]

> e dalla prossima versione ci sarà un metodo nuovo a risolvere il problema

...forse ho capito male, ma mi pareva che il tipo (Roland) dicesse che
la non lo renderanno pubblico nella prossima versione (" Anyways,
let's be clear about one thing, this functionality will not make it
for the version 1.0 release. "). Quando l'ho letto la cosa mi aveva
sorpreso e deluso, ma anche rassicurato sul fatto che sono tipi
cauti.

Mi piacerebbe sapere anche quali altri limiti hai riscontrato: apriamo
un altro thead?