Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 13
  1. #1

    PHP 5.3: lambda, closure e functor

    Noto con dispiacere che gli ultimi thread di rilievo relativi a PHP 5.3 in questa sezione risalgono a diversi mesi fa.
    Approfitto per segnalarvi che Sebastian Bergmann (bypasso i preliminari, chi programma in PHP è molto facile che sappia di chi sto parlando) ha messo online le slide dei suoi talk alla recente PHPCon Italia.

    In particolare, vi segnalo questa presentazione su lambda, closure e functor.
    http://www.slideshare.net/sebastian_...ures-in-php-53

    Il talk è stato molto interessante. La presentazione non è proprio come averlo vissuto dal vivo, ma meglio che nulla.
    Non so voi, ma sviluppando in parallelo su altri linguaggi, accolgo con entusiasmo l'arrivo soprattutto di lamda e closure.

    A proposito della PHPCon Italia 2009, altre slide sono disponibili all'indirizzo
    http://www.slideshare.net/tag/phpcon


  2. #2
    Utente di HTML.it L'avatar di oronze
    Registrato dal
    Jun 2001
    Messaggi
    3,543
    veramente interessanti...me le ero perse

    No ai layout tabellari!

    Insulto libero: http://forum.html.it/forum/showthread.php?s=&postid=12524872#post12524872

  3. #3
    JavaScript PHP like Object Class, come esempio di lambdas puo' andare?

    [edit]
    azz, I trait non li avevo affatto provati ... interessante. Questa slide in compenso manca di descrizione sulle lambda usate nelle classi, unico posto dove accettano il $this
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  4. #4
    Originariamente inviato da andr3a
    azz, I trait non li avevo affatto provati ... interessante.
    Sì, decisamente.
    Sarà possibile, ad esempio, creare un trait SIngleton e mixarlo all'interno delle classi che si desidera singletonizzare.

    Purtroppo i traits non sono parte di 5.3.

  5. #5
    Originariamente inviato da weppos
    Sarà possibile, ad esempio, creare un trait SIngleton e mixarlo all'interno delle classi che si desidera singletonizzare.
    ecco, per il Singleton credo che il trait sia l'ultima cosa da fare ... Singleton e' Singleton, non hai problemi di ereditarieta' multipla. Con late static bindings puoi gia' fare quello che ti pare, estendi Singleton e pace.
    codice:
    class Singleton {
        static  public  function    getInstance(){
            if(!isset(static::$_instance)){
                $arguments  = func_get_args();
                $i          = 0;
                switch(count($arguments)){
                    case    3:
                        static::$_instance  = new static($arguments[$i++], $arguments[$i++], $arguments[$i++]);
                        break;
                    case    2:
                        static::$_instance  = new static($arguments[$i++], $arguments[$i++]);
                        break;
                    case    1:
                        static::$_instance  = new static($arguments[$i++]);
                        break;
                    case    0:
                        static::$_instance  = new static;
                        break;
                    default:
                        throw new Exception('Would be nice to make it possible with new ReflectionClass(__CLASS__)->newInstanceArgs');
                        break;
                }
            }
            return  static::$_instance;
        }
    
        static  protected   $_instance;
    
        protected   function    __construct(){
            
        }
        
        public   function   __clone(){
            throw new Exception('Singleton is not cloneable');
        }
    }
    
    class MyS extends Singleton {
        static  protected   $_instance;
    }
    
    // true, true, true
    var_dump(
        Singleton::getInstance() === Singleton::getInstance()
    );
    var_dump(
        MyS::getInstance() === MyS::getInstance()
    );
    var_dump(
        Singleton::getInstance() != MyS::getInstance()
    );
    Io comunque tutto questo problema con l'ereditarieta' multipla non 'ho mai capito ... in primo luogo bisogna essere fagiani per incantarsi, secondo basta ridefinire il metodo se proprio necessario, terzo c'e' un ordine in extends ( A, B, C ) e seguendo quell'ordine mi aspetto metodo C sulla D senza problemi ... voglio dire, Python non ha mai avuto questo problema, ma ancora PHP prende il peggio di Java ed ignora il meglio di Python ... boh

    [edit]
    che poi non si capisce perche' per le interfaccie il problema non dovrebbe esistere ... ah no, ci sono i conflitti, e che li mettano anche sulla extends se vogliono essere logici ... ri-boh!
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  6. #6
    No, ferma, il mio riferimento al singleton non era riguardo l'ereditarietà multipla (anche se ovviamente il traits ha anche questo come fine), quanto alla riusabilità del codice.
    Invece di scrivere ogni volta la logica di un singleton, è sufficiente scriverla una volta sola e mixarla.

    Perché scrivere ogni volta decine di righe di codice in una classe, quando puoi farlo una volta sola (e testarlo una volta sola)?

  7. #7
    Originariamente inviato da weppos
    No, ferma, il mio riferimento al singleton non era riguardo l'ereditarietà multipla (anche se ovviamente il traits ha anche questo come fine), quanto alla riusabilità del codice.
    Invece di scrivere ogni volta la logica di un singleton, è sufficiente scriverla una volta sola e mixarla.

    Perché scrivere ogni volta decine di righe di codice in una classe, quando puoi farlo una volta sola (e testarlo una volta sola)?
    eh? cosa ti cambia usare use treatSingleton;
    o
    extends Singleton?

    ho pure scritto la classe di esempio da estendere ... non la devi scrivere per ogni Singleton, la usi e basta. Inoltre trat sul costruttore li vedo malissimo ... ma quello che faresti con i treat in Singleton, come gia' detto e mostrato, puoi gia' farlo senza problemi.

    Una classe estesa che implementa un singleton non presente nel parent ha, secondo me, qualcosa che non va a livello di logica. Io userei extends Singleton per quella classe e se proprio necessario treat per metodi comuni, non viceversa.
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  8. #8
    Una classe estesa che implementa un singleton non presente nel parent ha, secondo me, qualcosa che non va a livello di logica.
    Continuo a ribadire che non ho mai parlato di ereditarietà della classe singleton in nessuno dei miei due interventi precedenti.

    Tanto per darti un'idea di cosa sto parlando
    http://www.ruby-doc.org/stdlib/libdo...doc/index.html

  9. #9
    Originariamente inviato da weppos
    Tanto per darti un'idea di cosa sto parlando
    http://www.ruby-doc.org/stdlib/libdo...doc/index.html
    ma tu hai capito che il mio esempio basta che scrivi:
    codice:
    class TuaClass extends Singleton  {
        static  protected   $_instance;
    }
    e non devi fare nient'altro?

    Il link che mi hai postato descrive il Singleton, hai letto il mio codice? Quello e' Singleton, classe da estendere ... non ti servono i trait ... non so piu' come spiegarlo.

    Se tu vuoi definire un trait Singleton e usarlo per automatizzare Singleton, io ti dico che non hai bisogno di trait per farlo. Se parliamo di altro, polimorfismo o shared methods/lambdas, allora i trait possono tornare utili. Insomma, tutto tranne la Singleton, imho
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  10. #10
    ma tu hai capito che il mio esempio basta che scrivi:
    Certo, è esattamente quello che non voglio fare.
    Sono contrario all'uso dell'ereditarietà nel caso del singleton e comportamenti simili, in altre parole, non mi va di definire una classe come singleton e "Singletonizzare" una classe rendendola figlia della classe in questione.

    io ti dico che non hai bisogno di trait per farlo.
    Sono sopravvisssuto senza in PHP fino ad oggi, tuttavia lo ritengo un approcio produttivo in base all'esperienza maturata fino ad oggi.

    Detto questo, mi sembra di capire che implementeremmo il Singleton in due modi differenti. E anche questo non è sbagliato. Il design pattern descrive la soluzione, ma l'implementazione è delegata in base al linguaggio ed al contesto.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.