Reprise du message précédent :
Ouais enfin, si c'est pour faire un new sur une Classe pour n'utiliser qu'un bout de fonction, ben autant foutre cette méthode en statique

Bouef, j'ai jamais été fan de ce genre de choses.

$var = new MyClass()->myMethod();

foo()()

What the fucking fuck?

Non

Ca permet le chainage, et c'est sympathique le chainage en JS

Si la fonctionalité est utile (et utilisée) depuis une instance (et utilise potentiellement l'état de la dite instance) il est redondant de l'ajouter en statique  

Là je peux plus rien faire pour toi

// on PHP 5.4
$secondElement = getArray()[1];

$var = new MyClass()->myMethod();

tu peux avoir une classe avec plein de methode dont , pour une fois, tu ne veux en utiliser une seule

 
T'utilises ça dans quel contexte, toi?

Depuis quand on ne peut plus appeler une méthode statique à-partir d'une instance de la classe?

class A{
    static function lulz(){
        echo 'dawa';
    }
}
$a = new A;
$a->lulz();

 
J'ai pas d'exemple sous la main mais j'ai déjà eu à l'utiliser quelques fois. Rarement mais c'est déjà arrivé.

Builder Pattern, c'est super pratique pour configurer un objet de manière lisible et flexible, et ça évite d'avoir touzemille constructeurs avec des millions d'arguments

Genre (#2) jQuery, ou les queries de SQLAlchemy ou QuerySet Django:

q = session.query(User).\
        join(User.address).\
        filter(User.name.like('%ed%')).\
        order_by(Address.email)

class A{
    static function lulz(){
        echo 'dawa';
    }
}
$a = new A;
$a->lulz();

Tu pourrais lire les commentaires en entier et y réfléchir un peu avant de répondre des conneries

class A{
    static function lulz(){
        echo 'dawa';
    }
}
$a = new A;
$a->lulz();

 
Je parle d'une méthode non statique  
(new User($matricule)->getEmail() par exemple )

+1, très utile. Surtout dans les tests unitaires pour constuire des objets (cf. GOOS)

 
Ca parait fort peu probable pour une méthode qui peut être appelée via un $toto = new foo()->bar(), mais pourquoi pas...
 
Bref, amha si on a besoin d'instancier une classe juste pour en appeler une méthode c'est qu'il y a un soucis quelque part.

On t'a déjà donné une demi-douzaine d'examples

Ton avis n'est ni humble ni correct, qu'est ce que tu veux que je te dise de plus

Mais c'est le problème, justement...si tu as souvent besoin d'instancier ton User juste pour récupérer son matricule, pour moi tu as peut-être tout simplement besoin d'un User::getEmail($matricule).
Pourquoi instancier un objet potentiellement complexe si tout ce que tu veux au final c'est une chaîne de caractères?

 
J'en ai vu un. Builder. Si la méthode appelée retourne l'objet après avoir modifié son état c'est effectivement utilisable. Mais cela n'est qu'un moyen de simplifier l'écriture.
 

 
...et pourquoi il serait pas humble, mon avis?
Pour toute méthode qui ne retourne pas $this tu instancies un objet pour en perdre immédiatement la référence...je vois difficilement comment ça peut être une bonne idée.

Dans ce cas précis, t'as peut-être juste besoin de l'e-mail, mais la plupart du temps dans ton code t'as peut-être besoin de faire des tas d'opérations. Tu vas pas foutre une connexion à la BDD et tout le tintouin dans une méthode statique juste pour ce cas précis, non ?

 
ha ben oui
je vais creer des methodes statiques pour tout  
Et j'utilise les classes juste comme des namespaces.
 
Ces évolutions  ne permettent pas de faire plus, mais ça permet de le faire plus simplement
 
Non mais serieusement, tu remets en question ta façon de programmer des fois ? ou alors php avait atteint sa maturité quand tu l'as appris et la suite est inutile.

 
Tout dépend de ce que t'as à faire, mais instancier ton objet ça peut vouloir dire que tu vas aller interroger 3/4 tables, un annuaire, et que sais-je d'autre...alors qu'un pauvre select sur une table en connaissant la PK va te donner le résultat que tu veux.
Bref, ça dépend énormément du contexte, mais ça me choquerait pas forcément d'avoir une méthode dédiée, si c'est utilisé souvent comme ça.
Et si c'est pas utilisé souvent on en revient au problème de départ, ie la nouvelle fonctionnalité en question de php ne sert pas à grand chose.

 
Ah ben c'est sûr que si tu n'utilises tes accesseurs que comme ça je comprends que ça te paraisse essentiel, comme nouvelle fonctionnalité!

tu ne sais pas lire

T'as tout dit. Envisage qu'il y a des possibilités ou des besoins qui sont différents des tiens, c'est tout. C'est si difficile ?

 
C'est pas moi qui suis parti tout de suite dans la caricature et les attaques perso, hein...
Si pour toi ajouter/transformer quelques fonctions statiques pour des besoins précis ça revient vraiment à utiliser les classes comme des namespaces et ne jamais remettre en cause sa façon de travailler (look who's talking de platine! ) ça devient difficile de te répondre sérieusement, hein...

J'envisage.
Mais je ne trouve toujours rien qui fasse de la possibilité de faire $toto = new foo()->bar() une nouvelle fantastique.

C'est toi qui le déclare, j'en sais foutre rien

Voilà, parce que rajouter une méthode User::getEmail() qui est juste un alias sur User#getEmail c'est pas d'un grand intérêt.

Relis.
 

Si tu instancies fréquemment un User juste pour récupérer son email je vois l'intérêt d'avoir un moyen de le récupérer sans tout instancier, moi.
Et si tu ne le fais pas souvent, pouvoir écrire $email = new User($matricule)->getEmail(); au lieu de $user = new User($matricule); $email = $user->getEmail(); c'est pas franchement une nouveauté fantastique.

Pour revenir aux nouveautés de php 5.4, le premier qui utilise l'opérateur insteadof dans une application réelle a gagné une boite de paté!

Tiens d'ailleurs, les traits rendent obsolète l'ajout relativement récent de static::, non?

J'ai beau relire, c'est bel et bien toi qui a écrit:

non

En quoi va rendrait obsolète la résolution du la scope statique?

 
Dialogue de sourds, je crois. Tant pis.
 

 
Je parlais du late static binding, en fait. On doit maintenant pouvoir utiliser les Traits pour répondre de manière plus lisible au besoin. Non?

OK, je vois ce que tu veux dire maintenant. Il est pas humble parce que tu déclares que l'use case n'existe pas alors que t'as 5 mecs qui disent que ça leur a servi dans le passé  

Aucune idée, mais bon je connais pas trop le truc de LSB, ça m'a encore l'air d'être un hack pourri pour tenter de cacher des saletés de PHP, de loin.
 
edit: ok, je vois mieux ce que le LSB est. Je sais toujours pas si les traits seraient applicables, mais mon impression initiale se confirme, c'est un moyen d'avoir un comportement logique quand on override des méthode de classes.

Le LSB ça sert à résoudre ce genre de blague:

class A{
  static function foo(){
     self::bar();
  }
 
  static function bar(){
   echo 'A';
  }
}
 
class B extends A{
   static function bar(){
     echo 'B';
   }   
}
 
$b = B::foo();//Affiche A

Ouais, bon, voilà, t'étais allé voir.

'fin en tout cas c'est pas du tout le use-case pour les traits.

// on PHP 5.4
$secondElement = getArray()[1];

C'est lié au parser ça en plus, non?

ouais, finalement je me demande s'il y a moyen de les utiliser pour faire ça...je testerai à l'occasion.
Et il manquait tous les "static" dans mon exemple .

Oui, comme new Foo()->method().

 
function()(), tu veux dire {function()}() ou un truc dans le genre?