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

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

trait per decoratore standard

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

Contents

  trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-22 11:10 +0200
    Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-22 10:36 +0100
      Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-22 12:08 +0200
        Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-22 14:39 +0100
          Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-22 16:31 +0200
            Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-22 18:16 +0100
              Re: trait per decoratore standard fmassei@gmail.com - 2016-04-22 10:58 -0700
                Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-22 20:00 +0000
                  Re: trait per decoratore standard fmassei@gmail.com - 2016-04-22 14:01 -0700
                    Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-23 17:56 +0000
                      Re: trait per decoratore standard fmassei@gmail.com - 2016-04-24 22:16 -0700
                        Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-25 14:10 +0100
                Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-22 22:26 +0200
              Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-22 22:18 +0200
                Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-22 20:46 +0000
                  Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-23 10:30 +0200
                    Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-23 11:07 +0200
                      Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-23 11:32 +0200
                      Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-23 17:50 +0000
                        Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-24 10:36 +0200
                          Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-24 10:50 +0200
                          Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-24 11:28 +0000
                            Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-24 18:48 +0200
                          Re: trait per decoratore standard fmassei@gmail.com - 2016-04-24 22:19 -0700
                    Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-23 17:45 +0000
                      Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-24 10:26 +0200
                        Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-24 11:26 +0000
                          Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-26 14:50 +0200
                            Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-26 15:07 +0100
                              Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-26 21:11 +0200
                                Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-26 19:31 +0000
                                  Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-26 22:02 +0200
                                    Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-26 20:39 +0000
                                      Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-27 16:10 +0200
                                        Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-27 15:16 +0100
                                          Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-27 17:26 +0200
                      Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-29 17:42 +0200
                        Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-29 17:12 +0100
                          Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-30 13:20 +0200
                        Re: trait per decoratore standard fmassei@gmail.com - 2016-04-30 08:06 -0700
                          Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-30 21:26 +0200
                            Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-30 19:42 +0000
                              Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-30 23:20 +0200
                                Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-30 21:43 +0000
                                  Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-05-01 10:34 +0200
                              Re: trait per decoratore standard fmassei@gmail.com - 2016-04-30 14:38 -0700
                                Re: trait per decoratore standard Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-30 21:41 +0000
                                Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-05-01 10:45 +0200
                                  Re: trait per decoratore standard fmassei@gmail.com - 2016-05-01 09:02 -0700
                                    Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-05-02 10:45 +0200
        Re: trait per decoratore standard fmassei@gmail.com - 2016-04-22 07:12 -0700
          Re: trait per decoratore standard alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-22 16:44 +0200
            Re: trait per decoratore standard fmassei@gmail.com - 2016-04-22 07:58 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#20705

Il 24/04/2016 10:36, alex ha scritto:
>...

se poi vuoi un sistema di controllo maggiore (più intrinseco), le tue 
osservazioni sono giuste, e ci mancherebbe :P

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

#20707

Il Sun, 24 Apr 2016 10:36:55 +0200, alex ha scritto:

> Ma se ho il pieno controllo di quello che sto facendo potrebbe anche
> andar bene.

Se hai il pieno controllo di quello che stai facendo, nella maggior parte 
dei casi tutti i pattern astratti come questo non hanno senso.

Molti di questi pattern sono pensati per fare framework o librerie 
riutilizzabili, per condividere codice con altri sviluppatori, per riusare 
codice scritto da altri, ecc.

Se ti scrivi tutto tu da zero, non ha senso usarli.

Bye.

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

#20708

Il 24/04/2016 13:28, Alessandro Pellizzari ha scritto:
> Se ti scrivi tutto tu da zero, non ha senso usarli.

In effetti, poi dipende...
Vabè alla fine tutto è relativo :)

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

#20710

On Sunday, April 24, 2016 at 4:37:00 AM UTC-4, alex wrote:
> Ma se ho il pieno controllo di quello che sto facendo potrebbe anche 
> andar bene.
> 

Nah.
Quando scrivi codice, pensa sempre come se lo leggesse uno che non ha la
minima idea di quello che stai facendo. Se tutto va bene, quella persona
sarai te, tra un anno. E fidati no, non ti ricorderai *nulla* di quello che
hai in testa ora.
:)

Ciao!

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

#20700

Il Sat, 23 Apr 2016 10:30:11 +0200, alex ha scritto:

> Vero. Ma a questo punto userei la cara vecchia ereditarietà

Il che dimostra che non hai ancora capito bene a cosa servono i 
decoratori. :)

Niente di male, eh. Ci ho messo anche io un po', e finché non ho trovato 
un caso pratico in cui servissero non capivo nemmeno perché la gente li 
trovasse utili.

Con un singolo decoratore il discorso ha poco senso. Il senso arriva 
quando hai più decoratori che puoi wrappare in ordine diverso.
Quello che fai con una classe base e 3 decoratori può richiedere anche 
9-10 classi se usi l'ereditarietà.

Continuando l'esempio stupido del Log, pensa ad avere un decoratore che li 
stampa in HTML, uno che li salva in un DB, uno che li manda a Kibana, uno 
che li multiplexa.

$logger = new Log();

$htmlDb = new DbLog(new HtmlLog($logger));

$kibanaAndDb = new Multiplexer(new KibanaLog($logger), new DbLog($logger));

È un esempio stupido, perché alla fine del Log originale non rimane quasi 
niente, ma prova a fare il conto di quante combinazioni puoi creare coi 
decoratori e quante classi ti servono per farlo con l'ereditarietà.

Bye.

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

#20703

Il 23/04/2016 19:45, Alessandro Pellizzari ha scritto:
> È un esempio stupido, perché alla fine del Log originale non rimane quasi
> niente, ma prova a fare il conto di quante combinazioni puoi creare coi
> decoratori e quante classi ti servono per farlo con l'ereditarietà.
>

Non fraintendermi.
E' vero, alla fine ho sforato nell'editarità, senza tener conto di ciò 
che hai detto; hai ragione!!!
Però implementare funzioni inutili "{return $this->wrapped->get();}" 
(che wrappano la funzione di base, senza aggiungere altre funzionalità) 
lo eviterei.

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

#20706

Il Sun, 24 Apr 2016 10:26:18 +0200, alex ha scritto:

> Però implementare funzioni inutili "{return $this->wrapped->get();}"
> (che wrappano la funzione di base, senza aggiungere altre funzionalità)
> lo eviterei.

Quella è l'essenza stessa dei decoratori: fare override solo di alcune 
funzioni facendo transitare in modo trasparente tutte le altre.

Se non lo vuoi fare, non stai facendo un decoratore. :)

Bye.

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

#20712

Il 24/04/2016 13:26, Alessandro Pellizzari ha scritto:
> Quella è l'essenza stessa dei decoratori: fare override solo di alcune
> funzioni facendo transitare in modo trasparente tutte le altre.
>

Con conseguente impiego di codice inutile che crea confusione (è 
l'ultima cosa di cui un programmatore ha bisogno), e (seppur 
irrisoramente) diminuisce le prestazioni.

> Se non lo vuoi fare, non stai facendo un decoratore.:)

Infatti l'eredietà, usata con moderazione, non è da demonizzare :)

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

#20713

On 26/04/2016 13:50, alex wrote:

> Il 24/04/2016 13:26, Alessandro Pellizzari ha scritto:
>> Quella è l'essenza stessa dei decoratori: fare override solo di alcune
>> funzioni facendo transitare in modo trasparente tutte le altre.

> Con conseguente impiego di codice inutile che crea confusione (è
> l'ultima cosa di cui un programmatore ha bisogno), e (seppur
> irrisoramente) diminuisce le prestazioni.

Per l'impiego di codice basta una __call()
Per le prestazioni non ci puoi fare niente.

Ma i decoratori hanno una loro ragione di esistere. Non bisogna 
abusarne, come per qualsiasi altra cosa.

>> Se non lo vuoi fare, non stai facendo un decoratore.:)
>
> Infatti l'eredietà, usata con moderazione, non è da demonizzare :)

Mai detto il contrario, ma il segreto è sempre "con moderazione".

Appena il progetto cresce oltre un certo livello, fidati che 
l'ereditarietà diventa più un peso che un vantaggio, e sempre più spesso 
mi pento di averla usata.

In pratica, se ti trovi a estendere qualcosa di già esteso, stai 
sbagliando qualcosa.

Bye.

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

#20719

Il 26/04/2016 16:07, Alessandro Pellizzari ha scritto:
>>> Quella è l'essenza stessa dei decoratori: fare override solo di alcune
>>> funzioni facendo transitare in modo trasparente tutte le altre.
>
>> Con conseguente impiego di codice inutile che crea confusione (è
>> l'ultima cosa di cui un programmatore ha bisogno), e (seppur
>> irrisoramente) diminuisce le prestazioni.
>
> Per l'impiego di codice basta una __call()

in pratica come si può sfruttare (adesso non mi viene in mente)?

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

#20720

Il Tue, 26 Apr 2016 21:11:38 +0200, alex ha scritto:

>> Per l'impiego di codice basta una __call()
> 
> in pratica come si può sfruttare (adesso non mi viene in mente)?

class BlaDecorator {
 public function __call($method, $args) {
  return call_user_func_array([$this->wrapped, $method], $args);
 }
}


Bye.

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

#20721

Il 26/04/2016 21:31, Alessandro Pellizzari ha scritto:
> Il Tue, 26 Apr 2016 21:11:38 +0200, alex ha scritto:
>
>>> Per l'impiego di codice basta una __call()
>>
>> in pratica come si può sfruttare (adesso non mi viene in mente)?
>
> class BlaDecorator {
>   public function __call($method, $args) {
>    return call_user_func_array([$this->wrapped, $method], $args);
>   }
> }
>
>
> Bye.
>

interface A{
	function f();
}

class B implements A{
	function __call($a,$b) {
		;
	}
}


Fatal error: Class B contains 1 abstract method and must therefore be 
declared abstract or implement the remaining methods (A::f)

Ma che interpete usi?

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

#20723

Il Tue, 26 Apr 2016 22:02:38 +0200, alex ha scritto:

> interface A{
> 	function f();
> }
> 
> class B implements A{
> 	function __call($a,$b) {
> 		;
> 	}
> }
> 
> 
> Fatal error: Class B contains 1 abstract method and must therefore be
> declared abstract or implement the remaining methods (A::f)
> 
> Ma che interpete usi?

Hai ragione. Non l'avevo provato. :)

Allora puoi usare i trait. :P


interface A {
 public function f();
}

trait TA {
 public function f() {
  $this->wrapped->f();
 }
}

class B implements A
{
 public function f() {
  print "B\n";
 }
}

class C implements A {
 use TA;
 private $wrapped;

 public function __construct(A $wrapped)
 {
  $this->wrapped = $wrapped;
 }

 public function f() { print "C\n"; }
}

$c = new C(new B());
$c->f();

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

#20726

Il 26/04/2016 22:39, Alessandro Pellizzari ha scritto:
> class C implements A {
>   use TA;
>   private $wrapped;
>
>   public function __construct(A $wrapped)
>   {
>    $this->wrapped = $wrapped;
>   }
>
>   public function f() { print "C\n"; }
> }

Ma non si fanno queste cose.
Non ha senso usare un traid (per calpestarlo) e contemporaneamente 
implementare il metodo :-O

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

#20727

On 27/04/2016 15:10, alex wrote:

> Ma non si fanno queste cose.
> Non ha senso usare un traid (per calpestarlo) e contemporaneamente
> implementare il metodo :-O

Questo era un caso particolare con una sola funzione, e hai ragione che 
non ha senso.

Il caso generale prevede che un'interface abbia diversi metodi, e tu 
implementi tutte le funzioni dell'interface nel trait, allo stesso modo 
(lo so, è palloso e pessimo, ma non ci sono alternative), e poi nel 
decoratore sovrascrivi solo le funzioni che hanno un comportamento diverso.

Per il "calpestamento", il manuale dice questo:

The precedence order is that members from the current class override 
Trait methods, which in turn override inherited methods.

Quindi è previsto che si comporti così.

Bye.

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

#20728

Il 27/04/2016 16:16, Alessandro Pellizzari ha scritto:
> Per il "calpestamento", il manuale dice questo:
>
> The precedence order is that members from the current class override
> Trait methods, which in turn override inherited methods.

E' certo, anche se non è una soluzione proprio ottimale; pallosa appunto.

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

#20749

Il 23/04/2016 19:45, Alessandro Pellizzari ha scritto:
> $logger = new Log();
>
> $htmlDb = new DbLog(new HtmlLog($logger));
>
> $kibanaAndDb = new Multiplexer(new KibanaLog($logger), new DbLog($logger));

una curiosità: nella programmazione (non nell'ambito della musica o 
dell'elettronica) per multiplexer cosa si intende?

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

#20750

On 29/04/2016 16:42, alex wrote:

> Il 23/04/2016 19:45, Alessandro Pellizzari ha scritto:

>> $kibanaAndDb = new Multiplexer(new KibanaLog($logger), new
>> DbLog($logger));

> una curiosità: nella programmazione (non nell'ambito della musica o
> dell'elettronica) per multiplexer cosa si intende?

Io lo intendo come qualcosa che manda il segnale/dato a più destinazioni.

Non so se sia la definizione giusta. :D

Bye.

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

#20757

Il 29/04/2016 18:12, Alessandro Pellizzari ha scritto:
> On 29/04/2016 16:42, alex wrote:
>
>> Il 23/04/2016 19:45, Alessandro Pellizzari ha scritto:
>
>>> $kibanaAndDb = new Multiplexer(new KibanaLog($logger), new
>>> DbLog($logger));
>
>> una curiosità: nella programmazione (non nell'ambito della musica o
>> dell'elettronica) per multiplexer cosa si intende?
>
> Io lo intendo come qualcosa che manda il segnale/dato a più destinazioni.
>

In effetti...

> Non so se sia la definizione giusta. :D

Google

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

#20765

On Friday, April 29, 2016 at 11:42:54 AM UTC-4, alex wrote:
> una curiosità: nella programmazione (non nell'ambito della musica o 
> dell'elettronica) per multiplexer cosa si intende?
>

Io ho sempre pensato al corrispettivo del circuito multiplexer che si usa in
elettronica :)

Ciao!

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web