Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #20417 > unrolled thread

estendere le classi con gli eventi

Back to article view | Back to it.comp.www.php

Contents

  estendere le classi con gli eventi alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-02-26 19:54 +0100
    Re: estendere le classi con gli eventi fmassei@gmail.com - 2016-02-26 21:55 -0800
      Re: estendere le classi con gli eventi alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-02-27 08:42 +0100
        Re: estendere le classi con gli eventi fmassei@gmail.com - 2016-02-27 00:04 -0800
        Re: estendere le classi con gli eventi Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-29 10:59 +0000
          Re: estendere le classi con gli eventi Alex <tommaso5ita@yahoo.it> - 2016-02-29 12:47 +0100
          Re: estendere le classi con gli eventi alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-02-29 13:14 +0100
            Re: estendere le classi con gli eventi Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-29 14:24 +0000

#20417 — 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?

[toc] | [next] | [standalone]

#20418

On Friday, February 26, 2016 at 1:54:28 PM UTC-5, alex wrote:
> 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!

[toc] | [prev] | [next] | [standalone]

#20419

fmassei@gmail.com ha scritto:
> On Friday, February 26, 2016 at 1:54:28 PM UTC-5, alex wrote:
>> 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!
> 

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/

[toc] | [prev] | [next] | [standalone]

#20420

On Saturday, February 27, 2016 at 2:42:04 AM UTC-5, alex wrote:
> fmassei@gmail.com ha scritto:
> > On Friday, February 26, 2016 at 1:54:28 PM UTC-5, alex wrote:
> >> 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.
> >
> 
> Ok però a parte tutto, gli eventi li vedo utili solo per
>  implementare plugin, o l'ereditarietà multipla. O ci possono
>  essere altre utilità?
>

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!

[toc] | [prev] | [next] | [standalone]

#20425

On 27/02/2016 07:42, alex wrote:

> Ok però a parte tutto, gli eventi li vedo utili solo per
>   implementare plugin, o l'ereditarietà multipla. O ci possono
>   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.

[toc] | [prev] | [next] | [standalone]

#20429

Alessandro Pellizzari ha pensato forte :
> 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, 

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: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20431

Il 29/02/2016 11:59, Alessandro Pellizzari ha scritto:
>
> Per plugin dipende cosa intendi, perchè vuol dire tutto e niente.
>

intendo più o memo che (tratto da 
http://symfony.com/legacy/doc/jobeet/1_3/it/20?orm=Doctrine):

L'utilizzo primario dei plugin è quello di facilitare la condivisione di 
codice tra le applicazioni, o anche tra differenti progetti. Ricordiamo 
che gli applicativi symfony condividono solo il modello. I Plugin 
forniscono un modo per condividere più componenti tra gli applicativi.

> 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.
>

appunto

> 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.
>

giusto

> Ecco, alcuni (o tutti, dipende da come la vedi) li puoi considerare
> plugin, ma li puoi anche considerare microservices, componenti, servizi
> accessori, ecc.

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

[toc] | [prev] | [next] | [standalone]

#20432

On 29/02/2016 12:14, alex wrote:

> Il 29/02/2016 11:59, Alessandro Pellizzari ha scritto:
>>
>> Per plugin dipende cosa intendi, perchè vuol dire tutto e niente.

> intendo più o memo che (tratto da
> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web