Originariamente inviato da daniele_dll
disgraziatamente, anche se questo postulato è quasi sempre valido php rientra tra quei linguaggi che non considerano proprio per nulla

se è per questo il mio framework aveva smesso di funzionare tra php 5.2.6 e php 5.2.9 a causa di una serie di funzione che ritornavano valori con tipo diverso per indicare il fallimento

@dottwatson

l'idea della pillola non è male e le closures rendono infinitamente più semplice l'implementazione di un sistema ad eventi, di assai

Però, personalmente, preferisco:
- che sia la classe che necessita degli eventi ad estendere la classe base
- che la classe che necessità degli eventi non registri gli eventi a priori (anche se questo ti permette di fare maggiori controlli complica il codice, almeno in php)
- la rimozione degli eventi, almeno per una pagina web, non serve
- infine sarebbe più appropiato scegliere dei propri nomi per gli eventi

Riguardo l'ultimo punto, ti faccio un esempio pratico: se ho una proprietà {get|set}Age allora sarebbe appropriato chiamare l'evento changedAge (o ChangedAge, dipende dallo stile di coding utilizzato) ma non farlo richiamare direttamente da setAge bensì da un metodo di intermezzo chiamato ad esempio onChangedAge (o OnChagnedAge)

Questo semplice sistema permette di ridurre la duplicazione del codice quando si ci ritrova a dover richiamare l'evento da più posti, ad esempio un setPersonalInfo potrebbe acquisire anche l'eta e quindi dover richiamare l'evento changedAge cosa che ti costringerebbe a duplicare il codice.

Nell'esempio che ho postato, ovviamente, non c'è tutta questa differenza ma negli eventi è comune passare delle variabili con la conseguenza che va ad esempio costruito/inizializzato l'oggetto da passare o l'array ... o i valori necessari insomma e questo vorrebbe dire codice duplicato.

Infine piuttosto che utilizzare un metodo FireEvents per scatenare gli eventi sarebbe più utile usare il metodo magico __call cosi da semplificare il codice chiamate, però ci sarebbe di fare dei test di performance perché se non ricordo male non era molto performante :\

detto questo la trovo abbastanza utile
rispondo per steps:
Però, personalmente, preferisco:
- che sia la classe che necessita degli eventi ad estendere la classe base
vero sarebbe teoricamente piu logico, ma per renderla meno invasiva ho deciso di fare gestire gli eventi direttamente alla classe events, per quanto possano avere strettissima cooperazione sia la classe events che la classe utilizzatrice, ho preferito che events stesso gestisca gli eventi.

- la rimozione degli eventi, almeno per una pagina web, non serve
qual' ora uno si strutturerebbe con l'inizializzazione degli eventi in una fase di 'inizializzazione' potrebbe venire utile... se successivamente a==true l'evento rimane, viceversa removeEvent

infine sarebbe più appropiato scegliere dei propri nomi per gli eventi
ver. 0.1, e siceramente stavo già pensando a come poter gestire questa cosa in maniera semplice e non troppo pragmatica. Il mio scopo è di automatizzare il più possibile alcune procedure, scaricando lo sviluppatore dal dovere introdurre codice all' interno dei metodi


Ad ogni modo sono aperto a qualsiasi suggerimento e consiglio (sia logico che di codice)

Grazie dan!