Newsgroup: it.comp.www.php
Titolo: estendere le classi con gli eventi

come tutti sappiamo, c'è l'eredietarietà o si possono usare i 
decoratori; ma alcuni framework (symfony, cakephp) mettono a 
disposizione dei sistemi di events-dispatching.
Cosa ne pensate di questo sistema per estendere le classi?


Qui stai mischiando patate e carote :)
In quei framework il sistema event-driven è un paradigma di programmazione,
non ha nulla a che vedere con paradigmi o pattern architetturali.
 
Ciao!

fma...@gmail.com
 ha scritto:

Ok però a parte tutto, gli eventi li vedo utili solo per
 implementare plugin, o l'ereditarietà multipla. O ci possono
 essere altre utilità?
-- 
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
 


 
Vedila così: è un modo di gestire il flow del programma. E' un modo giusto?
Sbagliato? Si può fare altrimenti? Sì e no a tutte e tre le domande: è una
delle tante scelte tecniche possibili.
 
A me personalmente, in PHP server-side, non è mai andato giù perché
concettualmente non ha senso, ma architetturalmente rende più logiche certe
metodologie di sviluppo: ne hai detta una importante, sviluppare plugins
è più chiaro con sotto un sistema event-driven per chi viene da un particolare
mindset abbastanza diffuso.
Secondo me, a monte, al di là del mindset che si possiede, prima della
facilità di sviluppo (IMHO solo apparente, perché poi si finisce spesso
nell'overengineering) ci sono altre priorità, ma è un'idea mia: puoi
facilmente trovare chi ti dirà tutto il contrario di quanto ho scritto io
in queste ultime due frasi.
 
Ciao!

   essere altre utilità?
 
L'ereditarietà multipla è forse l'ultima cosa a cui penso, riguardo 
l'event dispatching.
 
Per plugin dipende cosa intendi, perchè vuol dire tutto e niente.
 
Un sistema ad eventi può essere utile, per esempio, per attaccare un 
logger o un profiler a un package, o in generale per lanciare 
elaborazioni parallele e trasparenti al normale flusso del programma, e 
per disaccoppiare i componenti.
 
Esempio stupido: un sistema di upload di immagini lancia un evento 
"uploaded" appena finito l'upload, e poi se ne frega se dietro non c'è 
niente o se magari c'è un task (anche accodato in gearman o simile) che 
prende quell'immagine e fa resize e cropping in 10-15 versioni diverse, 
magari salvando i dati in S3, o andando ad aggiornare il sistema di 
mailing in modo che alla prossima newsletter l'immagine venga inclusa, o 
che incrementi un contatore che manda una mail all'utente per dirgli 
quanti upload gli rimangono quel mese, o che posti l'immagine su 
twitter, ecc.
 
Ecco, alcuni (o tutti, dipende da come la vedi) li puoi considerare 
plugin, ma li puoi anche considerare microservices, componenti, servizi 
accessori, ecc.
 
Bye.
 
 
 

 che alla prossima newsletter l'immagine venga inclusa, 
 
Faccciamo una digressione, se me la passate, precisamente sul sistema 
di mailing di cui sei un esperto.
 
Se fai una mail rispettando *tutti* i criteri di Google che sono 
piuttosto restrittivi, ottieni che la mail passa i filtri di Google e 
viene effettivamente servita dai suoi server. Poi però succede che 
diversi provider nostrani, ci si è messo pure Aruba, non passano la 
stessa mail perché è fatta in modo tale che dichiara apertamente quello 
che è. Quindi: la conformità alla policy di Google impedisce il 
servizio di consegna da parte degli ISP di casa nostra.
 
Insomma un pasticcio. Anche abbastanza irritante.
Bye
 
 
 
-- 
Alex
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

 accessori, ecc.
 
cmq direi che alla fine è una delle tante tecniche da prendere in 
considerazione, con i relativi pregi/difetti
 

 
http://symfony.com/legacy/doc/jobeet/1_3/it/20?orm=Doctrine
):
 
Quella definizione di plugin è valida solo per Symfony 1.3, che è legacy 
e abbandonato da parecchio tempo.
 
Dalla 2.x, quelli che prima erano plugin ora si chiamano (più o meno) 
bundle, e anche in questo caso la definizione è valida solo per Symfony.
 
Bye.