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

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

raggruppamento delle variabili

Started byalex <1j9448a02@lnx159sneakemail.com.invalid>
First post2018-10-13 12:42 +0200
Last post2018-10-17 17:52 +0200
Articles 11 on this page of 31 — 5 participants

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

Contents

  raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-13 12:42 +0200
    Re: raggruppamento delle variabili fmassei@gmail.com - 2018-10-13 13:42 -0700
      Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-14 13:08 +0200
        Re: raggruppamento delle variabili fmassei@gmail.com - 2018-10-14 04:16 -0700
          Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-14 15:48 +0200
            Re: raggruppamento delle variabili fmassei@gmail.com - 2018-10-14 12:13 -0700
              Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-14 22:24 +0200
                Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-15 00:20 +0200
                  Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-15 18:26 +0200
                    Re: raggruppamento delle variabili Flavix <imeil@a.a> - 2018-10-17 17:45 +0200
                    Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-18 22:45 +0200
                      Re: raggruppamento delle variabili fmassei@gmail.com - 2018-10-18 15:45 -0700
                        Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-20 16:16 +0200
                          Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-21 11:46 +0200
                            Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-21 13:12 +0200
                              Re: raggruppamento delle variabili Flavix <imeil@a.a> - 2018-10-21 14:26 +0200
                                Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-21 15:07 +0200
                                  Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-21 15:11 +0200
                      Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-19 22:35 +0200
                        Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-20 22:36 +0200
                          Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-21 11:56 +0200
                            Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-21 13:13 +0200
                            Re: raggruppamento delle variabili Alessandro Pellizzari <shuriken@amiran.it> - 2018-10-22 10:11 +0100
                              Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-22 13:35 +0200
                                Re: raggruppamento delle variabili Alessandro Pellizzari <shuriken@amiran.it> - 2018-10-22 12:55 +0100
                                  Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-22 17:19 +0200
                                    Re: raggruppamento delle variabili Alessandro Pellizzari <shuriken@amiran.it> - 2018-10-22 16:31 +0100
                                      Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-22 17:56 +0200
                Re: raggruppamento delle variabili fmassei@gmail.com - 2018-10-14 21:38 -0700
                  Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-15 19:09 +0200
                  Re: raggruppamento delle variabili Flavix <imeil@a.a> - 2018-10-17 17:52 +0200

Page 2 of 2 — ← Prev page 1 [2]

#22318

Fromalex <1j9448a02@lnx159sneakemail.com.invalid>
Date2018-10-21 11:56 +0200
Message-ID<pqhifk$qt1$1@gioia.aioe.org>
In reply to#22316
Il 20/10/18 22:36, Leonardo Serni ha scritto:
> On Fri, 19 Oct 2018 22:35:43 +0200, alex
> <1j9448a02@lnx159sneakemail.com.invalid> wrote:
> 
>>> Tutte queste cose però diventano possibili e molte addirittura facilissime,
>>> con l'equipaggiamento giusto e un minimo di tempo per imparare a usarlo.
> 
>> Quindi è sbagliato ad esempio mettere tutte le funzioni di formattazione
>> in una classe (tool) a parte, che mi permette di concentrarmi solo su
>> quell'aspetto?
> 
> In generale credo non ci sia niente di sbagliato... e niente di giusto;
> bisogna capire come vanno le cose nell'economia di quel progetto.

Lo ripropongo: https://ibb.co/cKVUgL

>>>> Estrarre in un trait?
> 
>>> class Qualsiasi
>>> {
>>>       use \Traits\SimpleSingleton;
>>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>> E questo si chiama "estrarre il codice in una trait"
> 
> Io uso 'trait' al maschile, comunque sì. Prendi un certo tipo di codice
> che si riferisce a un "comportamento" della classe, lo tiri fuori dalle
> classi di quel tipo e lo metti in un trait.
> 
> Poi le varie classi reimportano quel trait. Uno "use", e hai fatto.

Quindi estraggono (attingono) il codice *dal* trait...

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

#22320

FromLeonardo Serni <lserni@gmail.com>
Date2018-10-21 13:13 +0200
Message-ID<npnosd98rf947rhtlgru3v9aqp1afnb6je@L.Serni>
In reply to#22318
On Sun, 21 Oct 2018 11:56:04 +0200, alex
<1j9448a02@lnx159sneakemail.com.invalid> wrote:

>Il 20/10/18 22:36, Leonardo Serni ha scritto:
>> On Fri, 19 Oct 2018 22:35:43 +0200, alex
>> <1j9448a02@lnx159sneakemail.com.invalid> wrote:
>> 
>>>> Tutte queste cose però diventano possibili e molte addirittura facilissime,
>>>> con l'equipaggiamento giusto e un minimo di tempo per imparare a usarlo.
>> 
>>> Quindi è sbagliato ad esempio mettere tutte le funzioni di formattazione
>>> in una classe (tool) a parte, che mi permette di concentrarmi solo su
>>> quell'aspetto?
>> 
>> In generale credo non ci sia niente di sbagliato... e niente di giusto;
>> bisogna capire come vanno le cose nell'economia di quel progetto.
>
>Lo ripropongo: https://ibb.co/cKVUgL

(So ^Ke molti mi aspettavano al varco da mesi)

Leonardo
-- 

"You all presumably know why" :-) :-(

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

#22325

FromAlessandro Pellizzari <shuriken@amiran.it>
Date2018-10-22 10:11 +0100
Message-ID<g35ih4Frb68U1@mid.individual.net>
In reply to#22318
On 21/10/2018 10:56, alex wrote:

> Quindi estraggono (attingono) il codice *dal* trait...

Tu, programmatore, estrai il codice IN (moto a luogo) un trait.

La classe importa codice DAL (moto da luogo) trait.

Bye.

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

#22326

Fromalex <1j9448a02@lnx159sneakemail.com.invalid>
Date2018-10-22 13:35 +0200
Message-ID<pqkcm2$14c0$1@gioia.aioe.org>
In reply to#22325
Il 22/10/18 11:11, Alessandro Pellizzari ha scritto:
> On 21/10/2018 10:56, alex wrote:
> 
>> Quindi estraggono (attingono) il codice *dal* trait...
> 
> Tu, programmatore, estrai il codice IN (moto a luogo) un trait.

Appunto tu hai specificato esplicitamente il soggetto.
Di solito, nell'ambito della programmazione, ci si riferisce alla 
macchina, all'interprete php, e non alla persona umana (programmatore).

> La classe importa codice DAL (moto da luogo) trait.

Ancora c'è qualcuno che usa la lingua italiana correttamente :D

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

#22327

FromAlessandro Pellizzari <shuriken@amiran.it>
Date2018-10-22 12:55 +0100
Message-ID<g35s5fFtbcuU1@mid.individual.net>
In reply to#22326
On 22/10/2018 12:35, alex wrote:

> Il 22/10/18 11:11, Alessandro Pellizzari ha scritto:

>> Tu, programmatore, estrai il codice IN (moto a luogo) un trait.
> 
> Appunto tu hai specificato esplicitamente il soggetto.
> Di solito, nell'ambito della programmazione, ci si riferisce alla 
> macchina, all'interprete php, e non alla persona umana (programmatore).

Uhm... no. :)

Leonardo ha detto a te, programmatore, di prendere il codice da una 
classe e di muoverlo dentro un trait.

Scrivere codice è il lavoro del programmatore, non della macchina o 
dell'interprete, quindi "estrai il codice (e mettilo) in un trait" è 
riferito al programmatore, quindi è corretto "in" e non "da".

Giusto per fare il grammar nazi. :)

Bye.

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

#22328

Fromalex <1j9448a02@lnx159sneakemail.com.invalid>
Date2018-10-22 17:19 +0200
Message-ID<pqkq2q$1tba$1@gioia.aioe.org>
In reply to#22327
Il 22/10/2018 13:55, Alessandro Pellizzari ha scritto:
> On 22/10/2018 12:35, alex wrote:
> 
>> Il 22/10/18 11:11, Alessandro Pellizzari ha scritto:
> 
>>> Tu, programmatore, estrai il codice IN (moto a luogo) un trait.
>>
>> Appunto tu hai specificato esplicitamente il soggetto.
>> Di solito, nell'ambito della programmazione, ci si riferisce alla 
>> macchina, all'interprete php, e non alla persona umana (programmatore).
> 
> Uhm... no. :)
> 
> Leonardo ha detto a te, programmatore, di prendere il codice da una 
> classe e di muoverlo dentro un trait.

Diciamo che non ha usato la dicitura più comune(software side): la 
classe deve estrarre il codice, di cui ha bisogno, dall'apposito trait.
E sono rimasto un po' spiazzato :D

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

#22329

FromAlessandro Pellizzari <shuriken@amiran.it>
Date2018-10-22 16:31 +0100
Message-ID<g368qpF1d0fU1@mid.individual.net>
In reply to#22328
On 22/10/2018 16:19, alex wrote:

> Diciamo che non ha usato la dicitura più comune(software side): la 
> classe deve estrarre il codice, di cui ha bisogno, dall'apposito trait.

Onestamente non l'ho mai sentita, messa così.

Al massimo la classe importa (da cui le keyword "import" e "include" 
comuni a molti linguaggi) il codice da un trait, ma "estrarre" ha sempre 
significato "togliere", non "mettere".

Bye.

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

#22330

Fromalex <1j9448a02@lnx159sneakemail.com.invalid>
Date2018-10-22 17:56 +0200
Message-ID<pqks7c$26m$1@gioia.aioe.org>
In reply to#22329
Il 22/10/2018 17:31, Alessandro Pellizzari ha scritto:
> On 22/10/2018 16:19, alex wrote:
> 
>> Diciamo che non ha usato la dicitura più comune(software side): la 
>> classe deve estrarre il codice, di cui ha bisogno, dall'apposito trait.
> 
> Onestamente non l'ho mai sentita, messa così.
> 
> Al massimo la classe importa (da cui le keyword "import" e "include" 
> comuni a molti linguaggi) il codice da un trait, ma "estrarre" ha sempre 
> significato "togliere", non "mettere".
> 
> Bye.

Cmq il verbo esatto (da attribuire al programmatore) sarebbe stato 
*spostare* (non *estrarre*).
"Prendi il codice dalla classe, e lo *sposti* in un trait"

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

#22301

Fromfmassei@gmail.com
Date2018-10-14 21:38 -0700
Message-ID<823e389f-20cf-43d0-8b3b-5e57368079eb@googlegroups.com>
In reply to#22299
On Sunday, October 14, 2018 at 4:29:31 PM UTC-4, alex wrote:
> Il 14/10/2018 21:13, fmassei@gmail.com ha scritto:
> > A me pure piace così, costanti, variabili, funzioni.
> > Per public/protected/private io personalmente non ci faccio molto caso a
> > patto che le funzioni stiano insieme per visibilità, perché se la classe
> > è lunga, e non hai un IDE di qualche tipo, comunque devi scorrerne gran
> > parte per leggerla. La più accreditata che ho visto, comunque, è mettere
> > prima gli overload,
> 
> Cioè le funzioni ereditate?
> 

"funzioni ereditate"... sì, anche se non è proprio corretto come termine,
penso tu abbia afferrato quel che dicevo ;)


> > poi le funzioni private, e le public in fondo.
> 
> Io metto:
> 
> getInstance() (se la classe è singleton)
> costruttore
> metodo principale della classe
> eventuali altri metodi: i cosiddetti tools (metodi di supporto)
>

"tools" anche, non l'ho mai sentito dire :)

Occhio anche a questa cosa del "singleton" che dici ongi tanto: è uno dei
pattern più famosi che si studiano, ma è anche quello meno usato. Di
singleton in un progetto ne userai al massimo uno o due, e se usi un DI
per creare le classi on demand, come fanno quasi tutti, non ne usi nemmeno
uno.
 
> Anche se l'ideale sarebbe avere micro-classi (con non più di tre metodi):
> 
> getInstance() (se la classe è singleton)
> costruttore
> metodo principale della classe
> e ogni tools in altrettante singole classi.
>

Come ha detto Leonardo, questo non ha molto senso: ogni classe implementa
i metodi che le competono. Fare una classe solo per isolare due/tre funzioni
è il primo passo per diventare un javista ;)


Ciao!

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

#22303

Fromalex <1j9448a02@lnx159sneakemail.com.invalid>
Date2018-10-15 19:09 +0200
Message-ID<pq2hjf$udj$1@gioia.aioe.org>
In reply to#22301
Il 15/10/2018 06:38, fmassei@gmail.com ha scritto:
>>> poi le funzioni private, e le public in fondo.
>>
>> Io metto:
>>
>> getInstance() (se la classe è singleton)
>> costruttore
>> metodo principale della classe
>> eventuali altri metodi: i cosiddetti tools (metodi di supporto)
>>
> 
> "tools" anche, non l'ho mai sentito dire :)

class DirName {

     //...

     function sanitize() {
         return DirName\Sanitizer::sanitizze(// tool di sanitizazione
             $this->name;
         );
     }

     //...

}

> Occhio anche a questa cosa del "singleton" che dici ongi tanto: è uno dei
> pattern più famosi che si studiano, ma è anche quello meno usato. Di
> singleton in un progetto ne userai al massimo uno o due, e se usi un DI
> per creare le classi on demand, come fanno quasi tutti, non ne usi nemmeno
> uno.
>   

Certo, infatti ti riporto quanto avevo scritto

"getInstance() (se la classe è singleton)"

Forse non avevi notato la nota tra parentesi.

>> Anche se l'ideale sarebbe avere micro-classi (con non più di tre metodi):
>>
>> getInstance() (se la classe è singleton)
>> costruttore
>> metodo principale della classe
>> e ogni tools in altrettante singole classi.
>>
> 
> Come ha detto Leonardo, questo non ha molto senso: ogni classe implementa
> i metodi che le competono. Fare una classe solo per isolare due/tre funzioni
> è il primo passo per diventare un javista ;)

Anche incorporare nella stessa classe un tool (sanitizer, converter, 
validator...) di 50 e più righe non lo trovo conveniente.
Semmai ti crei una classe specializzata che potrebbe anche essere 
riutilizzabile.

Una libreria in genere è formata da un unica classe?
Cioè da un bel monoblocco monolitico?

O da più classi che consentono di organizzare meglio il codice, dando 
anche maggiore flessibilità?

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

#22311

FromFlavix <imeil@a.a>
Date2018-10-17 17:52 +0200
Message-ID<pq7m4f$1amm$1@gioia.aioe.org>
In reply to#22301
Il 15/10/2018 06:38, fmassei@gmail.com ha scritto:
> On Sunday, October 14, 2018 at 4:29:31 PM UTC-4, alex wrote:
>> Il 14/10/2018 21:13, fmassei@gmail.com ha scritto:
>>> A me pure piace così, costanti, variabili, funzioni.
>>> Per public/protected/private io personalmente non ci faccio molto caso a
>>> patto che le funzioni stiano insieme per visibilità, perché se la classe
>>> è lunga, e non hai un IDE di qualche tipo, comunque devi scorrerne gran
>>> parte per leggerla. La più accreditata che ho visto, comunque, è mettere
>>> prima gli overload,
>>
>> Cioè le funzioni ereditate?
>>
> 
> "funzioni ereditate"... sì, anche se non è proprio corretto come termine,
> penso tu abbia afferrato quel che dicevo ;)

Soprattutto per chi non usa i decoratori: ormai la tendenza è questa.

>> Anche se l'ideale sarebbe avere micro-classi (con non più di tre metodi):
>>
>> getInstance() (se la classe è singleton)
>> costruttore
>> metodo principale della classe
>> e ogni tools in altrettante singole classi.
>>
> 
> Come ha detto Leonardo, questo non ha molto senso: ogni classe implementa
> i metodi che le competono. Fare una classe solo per isolare due/tre funzioni
> è il primo passo per diventare un javista ;)

Neanche una classe con 20 metodi però è il massimo.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web