Peut-être précisément parce que tu n'as pas encore accordé à PHP un label « Professionnel ». À l'occasion d'une soirée restau de ViPhP, c'est Cyruss(*) qui nous avait évoqué cet aspect en nous disant (je paraphrase de mémoire) : «faire un site internet, c'est quasiment à la portée du premier couillon venu, mais si on est (ou se veut être) un développeur, il ne faut pas penser « site web » mais application logicielle » et je suis complètement d'accord avec lui. Et si tu te considères comme développeur, ce serait bien d'avoir des arguments de développeur et pas des arguments d'intégrateur pour défendre ton point de vue sur les traits.

Entièrement d'accord ... cela dit ton argument sur le sujet est auto destructeur ... tu ne peux pas considérer faire une utilisation professionnelle d'une apli développée avec une version 5.4 Alpha 0.2 ....

sinon, franchement, je songe grandement à l'intégration à court termes (lors de la sortie d'une version stable) des traits qui sont selon moi une bonne idée !...
Description du concept ::
Je bosse à un échelon (on est 4 ... donc c'est pas trop compliqué ^^) qui me permet de définir le fonctionnement de l’application, je défini la structure conceptuelle des objets, défini les interfaces, et autres contraintes fonctionnelles des objets.
Donc, lorsqu'une apli remonte buggé il est rapide de la passer dans une batterie de tests pour vérifier le respect de son fonctionnement.
et il m'est possible de forcé l'implémentation de méthodes qui sont présentes exclusivement dans les classes destinées à l'héritage horizontal.

les traits servent donc selon moi à définir des propriété et méthodes communes à plusieurs objets dont les parent (héritage vertical) n'ont pas la nécessite de diffuser à l'ensemble de leurs héritiers ...

ex : 7 objets A, B, C, D, E, H et T
A et B sont des héritiers (extends) de H
C et D sont héritiers de E qui est Héritier de H

B et D ont des méthodes communes ... je leurs joins un trait T plutôt que de faire hériter tous mes objets de ses méthodes ou de dupliquer mon code!....

Ôte-moi d'un doute : tu développes des sites web ou tu intègres des CMS tout faits et vaguement bidouillés selon les besoins ponctuels ? Parce que dans ce cas je peux comprendre que ce soit une cause supplémentaire de difficultés de lecture de code : si on intègre ce genre de méthodologies dans un Joomla ou un Wordpress et que tu arrives de moins en moins simplement à les personnaliser, je conçois volontiers que ça te hérisse le poil.

dans ce cas là, justement, tu pourrait facilement modifier le comportement des méthodes natives à la solution en ne faisant qu'ajouter use maClasseDeMethodesPerso au lieu de taper directement dans le code source tortueux de l'apli !....
Ainsi, une mise à jour serait rapidement intégré !...

Toujours pour les mises à jour, l'héritage horizontale permettrait d'envisager des mise à jours progressives par patchs avant intégration définitive dans le corps de l'apli ...

Attention à ne pas rentrer dans une guerre de clocher

Acceptons la diversité des avis, et échangeons calmement en expliquant pourquoi on préfère telle ou telle voie, mais essayons de ne pas tomber dans le "je ne comprend pas comment tu peux penser ça"

Ôte-moi d'un doute : tu développes des sites web ou tu intègres des CMS tout faits et vaguement bidouillés selon les besoins ponctuels ? Parce que dans ce cas je peux comprendre que ce soit une cause supplémentaire de difficultés de lecture de code : si on intègre ce genre de méthodologies dans un Joomla ou un Wordpress et que tu arrives de moins en moins simplement à les personnaliser, je conçois volontiers que ça te hérisse le poil.

dans ce cas là, justement, tu pourrait facilement modifier le comportement des méthodes natives à la solution en ne faisant qu'ajouter use maClasseDeMethodesPerso au lieu de taper directement dans le code source tortueux de l'apli !....
Ainsi, une mise à jour serait rapidement intégré !... ...

C'est à mon sens précisément le nœud du problème. Les traits sont à mon sens (et je crois que plusieurs développeurs partagent cet avis) une excellente amélioration. mais reste le problème a la bonne mise en œuvre de leur utilisation. Pour un CMS par exemple, on peut effectivement simplifier pas mal de choses sans que ça rende plus compliquée son intégration personnalisée, ni pour autant l'améliorer puisque ce n'est pas le but des traits qui ne concerne que la programmation pure et dure, à la condition toutefois qu'on ne tombe pas sur un développeur de CMS qui tombe dans l’excès par une utilisation abusive et inappropriée. Et ce n'est que ce point que je voulais soulever par mes observations. Il n'est nullement question de guerre de clocher, chaque amélioration d'un langage est faite à la base pour en faciliter et/ou simplifier l'utilisation : les traits en PHP ne font pas du tout exception à cette règle.

... mais reste le problème a la bonne mise en œuvre de leur utilisation ...
... à la condition toutefois qu'on ne tombe pas sur un développeur de CMS qui tombe dans l’excès par une utilisation abusive et inappropriée ...

Bien sur !... =D>
et d'ailleurs, certains développeurs devrait être interdits de toucher un PC, même de loin ... mais c'est un autre débat

chaque amélioration d'un langage est faite à la base pour en faciliter et/ou simplifier l'utilisation

Pas du tout. Au vue de toutes les "améliorations" auxquels on a eu droit ces dernières années, les langages devrait être tellement simple qu'un enfant (ou pire pour vous : un intégrateur de CMS) devrait pouvoir développer les yeux fermés. Et bien non, comme sur un site web, ajouter une nouvelle fonctionnalité crée des problèmes subtiles et des cas d'utilisations limites voir incorrects qui complique la tâche du développeur.

Je ne demande bien sûr qu'a me tromper. Si demain, on me montre un cas d'utilisation des traits dont les bénéfices sont tellement évidents, et bien, j'embrasserai cette nouvelle technique. Mais, en ce qui concerne mes développement, je préfère resté seul juge de ce que je trouve pertinent ou pas(*). Il ne me viendrait pas à l'idée de dire à quelqu'un qu'il est "le premier couillon venu", parce qu'il utilise les traits : grand bien lui fasse et il est nécessaire d'avoir des pionniers kamikazes dans ce domaine

(* et par exemple, comme j'ai aussi laissé tombé le singleton, le cas exposé ne m'apporte hélas pas grand chose)

(PS: je n'utilise jamais de CMS )

Hum j'vais p'tet dire une connerie, mais apres tout la correction me sera sûrement utile

Un exemple qui me parait (et deja invoqué) serait la librairie de fonction (dll style :green: )
Perso j'avais une classe de gestion du sgbd (remplacée par pdo mais le soucis reste) dont toute mes classes héritée parce je trouvais pas forcement mieux d'avoir un objet pdo (bon choix perso).
Au fur et a mesure de mes, heu développement je me suis constitué des fonctions, puis une classes le permettant un tas de chose utile (de la gestion des magic quote, au formatage des URL pour le mod rewrite etc. )
Je me trouvais donc dans le soucis de ne pas pouvoir utiliser cette classe en tant que parent dans mes classes "métier" donc soit j'avais un objet pdo soit un objet fonction (la classes de fonction n'est pas en singleton parce que heu j'en suis pas familier )
La pour le coup les classes peuvent hériter de pdo et utiliser, en "natif", les méthodes de la classe utilitaire qui pour le coup devient un trait

J'ai aussi pensé au coup des hooks et "plugins", avec une formalisation bien définie on peut tres bien imaginer utiliser les traits pour cela ?

@+

Je crois que tu as fort bien compris et résumé comment les traits pouvaient pallier ce problème de fonctions utilitaires

Je crois que tu as fort bien compris et résumé comment les traits pouvaient pallier ce problème de fonctions utilitaires

boaf, la classe db devrait être statique, et pas hérité (que ca soit via trait ou pas) dans un objet métier et utilisé directement comme suit

$result = db::query('SELECT truc FROM machin WHERE truc=\'super\';')

je vois pas ce que trait apporte, mis à part une nouvelle façon de faire des choses qu'on peut faire autrement... et pas forcément mieux conceptuellement en plus...

je vois pas ce que trait apporte, mis à part une nouvelle façon de faire des choses qu'on peut faire autrement... et pas forcément mieux conceptuellement en plus...

comme toutes évolutions, ça n'apportes rien de plus, mais de nouvelles méthodologies fonctionnelles qui, dans certains contextes peuvent s'avérer bien plus pratique/rentable/utile

pour ma part je suis fan du JsonSerializable, ça va être encore plus simple de passer d'un langage vers un autre,
sinon enfin le Transliterator pour intl, (finis les problèmes de langue), le SpoofChecker pour les URL, l'upload progress via les sessions, le support de DTrace, l'array dereferencing (mais j'aurai aimé la même chose pour les objets genre : new Test()->machin())

Non mais on va pas se disputer sur les traits ^^

Je vais vous dire, je passe généralement plus de temps à réfléchir sur ma façon de coder que sur le code lui-même. Il est si facile de faire quelque chose de fonctionnel, par exemple en procédural. Mais, au delà du fonctionnel, je trouve la beauté des lignes.

Si PHP devait rester au rang des langages de script, qu'on se le dise, je vous dirais au revoir et je partirai sur Java. Mais j'ai "grandi" avec PHP, et je m'efforce de trouver chez lui le maximum qu'il peut faire pour ressembler aux langages full Object. Alors, oublier toutes les belles choses, hors de question ! Je ne reviendrai plus au procédural. Et je n'attends qu'une chose, c'est que PHP se développe encore.

Cela dit, autant j'ignore les traits pour les problèmes de version (je n'arrive même pas à créer une seule application en php 5.3 sauf si elle est destinée à mon propre serveur !!!), autant je trouve que c'est une bonne chose. Et tout comme les namespaces, on peut s'en passer si on n'y voit pas l'utilité. Mais c'est sûr qu'à forcer de rester sur des CMS codés en PHP 4 et des frameworks codés pour de vieilles versions (plus ou moins), on n'apprendra jamais les bonnes habitudes. Le choix est alors à la fois une bonne chose, et une mauvaise. Personnellement, j'aime bien être encadré, alors j'adopte les conventions de codage, et les bonnes façons.

Par contre, les développeurs de PHP ont aussi de drôles d'idées, et visent certainement plusieurs fronts à la fois, et je trouve cela mauvais car pour le coup, on est vraiment perdu, j'aime être tenu par des conventions, des frameworks, etc. Et quand je parle de drôles d'idées, je parle par exemple de ... GOTO ...

C'est très drôle les goto, mais bon ... à côté, quand on a 6 boucles imbriquées, c'est galère de faire "continue 6;", nommer serait quand même une fonctionnalité plus utile ...

Si PHP devait rester au rang des langages de script, qu'on se le dise, je vous dirais au revoir et je partirai sur Java. Mais j'ai "grandi" avec PHP, et je m'efforce de trouver chez lui le maximum qu'il peut faire pour ressembler aux langages full Object. Alors, oublier toutes les belles choses, hors de question ! Je ne reviendrai plus au procédural. Et je n'attends qu'une chose, c'est que PHP se développe encore.

Le full object est une absurdité et la raison principale qui fait de java et de dot net des langages lents et couteux en ram, si tu y vois une "progression" moi j'y vois une regression, comment faire la même chose qu'il y a dix ans en nécessitant des machines plus puissantes, et en perdant au passage une bonne partie de la maîtrise du code réel.

Cela dit, autant j'ignore les traits pour les problèmes de version (je n'arrive même pas à créer une seule application en php 5.3 sauf si elle est destinée à mon propre serveur !!!), autant je trouve que c'est une bonne chose. Et tout comme les namespaces, on peut s'en passer si on n'y voit pas l'utilité. Mais c'est sûr qu'à forcer de rester sur des CMS codés en PHP 4 et des frameworks codés pour de vieilles versions (plus ou moins), on n'apprendra jamais les bonnes habitudes. Le choix est alors à la fois une bonne chose, et une mauvaise. Personnellement, j'aime bien être encadré, alors j'adopte les conventions de codage, et les bonnes façons.

Sans parler des trait spécifiquement, il me semble que ce que les gens qui font php décident en terme d'évolution du langage ne fait pas office de référence ultime, l'intérêt de php est d'être un langage légé et très adapté de parts ses modules aux problématiques du développement web, rajouter des sur-couches objets juste pour faire comme java, je suis vraiment pas fan, il y a des bonnes choses dans php, de la à dire que tout est bon c'est manquer de discernement.

Par contre, les développeurs de PHP ont aussi de drôles d'idées, et visent certainement plusieurs fronts à la fois, et je trouve cela mauvais car pour le coup, on est vraiment perdu, j'aime être tenu par des conventions, des frameworks, etc. Et quand je parle de drôles d'idées, je parle par exemple de ... GOTO ...

C'est très drôle les goto, mais bon ... à côté, quand on a 6 boucles imbriquées, c'est galère de faire "continue 6;", nommer serait quand même une fonctionnalité plus utile ...

un code qui contient des séquence de plus de 3 (idéalement 2) boucles imbriquées c'est un code raté, si tu as du code comme ça il faudrait vraiment que tu ailles le relire tu trouveras certainement une meilleure manière de l'écrire en cherchant 5 minutes...

Non. A priori, l'imbrication de boucles peut paraître une mauvaise chose dans le code que je donne comme exemple. Cependant, c'est très rare que j'utilise autant d'imbrications, et là, c'est pour un rôle bien spécifique. En réalité, il n'y a que 4 boucles il me semble, une pour parcourir un tableau, une autre pour parcourir un autre tableau, une autre pour parcourir le même tableau (comparaison entre deux objets de ce même tableau), une autre pour parcourir des éléments de chaque objet de ce dernier tableau, puis enfin des conditions. Il me semble que c'est tout. Il faut quand même voir qu'il y a certaines conditions qui permettent de sortir d'un ensemble de boucle lorsque une ou plusieurs conditions sont remplies. Pour le coup, un vrai casse-tête à développer mais au final, un bon plaisir ... Il fallait tester toutes les combinaisons possibles.

(Je te laisse imaginer le fonctionnement de http://applications.devlopnet.com/mots_croises/, et tu pourras imaginer tous les tests de possibilité à faire pour bien placer les éléments, et pourtant le code est rapide car il sort des boucles dès qu'il a atteint son objectif).

Après dans le full object, je vois surtout le typage fort, et ça me manque beaucoup. Evidemment, le casting permet de faire le code voulu, mais ça passe à côté. Ensuite, je trouve les fonctions PHP qui font un peu dans tous les sens, et je ne suis pas le seul à le penser ... L'ordre des arguments n'est pas toujours logique ou la même logique, on a des fois des fonctions qui commencent par array_ d'autres pas, pour les tableaux, etc. Avoir un $string->toUpper() serait un must pour moi Sans aller jusqu'au full object, ça peut être du prototypage, mais je ne voudrais pas trop m'avancer là dessus car je n'apprécie pas non plus Javascript pour sa conception objet, par contre je préfère son écriture.

Non. A priori, l'imbrication de boucles peut paraître une mauvaise chose dans le code que je donne comme exemple. Cependant, c'est très rare que j'utilise autant d'imbrications, et là, c'est pour un rôle bien spécifique. En réalité, il n'y a que 4 boucles il me semble, une pour parcourir un tableau, une autre pour parcourir un autre tableau, une autre pour parcourir le même tableau (comparaison entre deux objets de ce même tableau), une autre pour parcourir des éléments de chaque objet de ce dernier tableau, puis enfin des conditions. Il me semble que c'est tout. Il faut quand même voir qu'il y a certaines conditions qui permettent de sortir d'un ensemble de boucle lorsque une ou plusieurs conditions sont remplies. Pour le coup, un vrai casse-tête à développer mais au final, un bon plaisir ... Il fallait tester toutes les combinaisons possibles.

(Je te laisse imaginer le fonctionnement de http://applications.devlopnet.com/mots_croises/, et tu pourras imaginer tous les tests de possibilité à faire pour bien placer les éléments, et pourtant le code est rapide car il sort des boucles dès qu'il a atteint son objectif).

Je reste sur mon avis, c'est juste pas possible d'avoir une bonne raison d'imbriquer autant de boucles c'est algorithmique...

Après dans le full object, je vois surtout le typage fort, et ça me manque beaucoup. Evidemment, le casting permet de faire le code voulu, mais ça passe à côté. Ensuite, je trouve les fonctions PHP qui font un peu dans tous les sens, et je ne suis pas le seul à le penser ... L'ordre des arguments n'est pas toujours logique ou la même logique, on a des fois des fonctions qui commencent par array_ d'autres pas, pour les tableaux, etc. Avoir un $string->toUpper() serait un must pour moi Sans aller jusqu'au full object, ça peut être du prototypage, mais je ne voudrais pas trop m'avancer là dessus car je n'apprécie pas non plus Javascript pour sa conception objet, par contre je préfère son écriture.

Le typage fort n'a rien à voir avec cet aspect la d'un langage, le typage fort consiste à ce que tu doives déclarer une variable et son type avant de pouvoir l'utiliser, plutôt que de lui donner un type à travers le type de la valeur que tu lu donnes, c'est une question de préférence mais perso je déclare mes variables comme si le typage était fort de toutes les manières, à savoir un truc du genre:

$texte = '';

$texte .= 'truc ';
$texte .= 'machin';

Pour les fonctions php qui font des trucs pas logiques, je vois pas non plus le rapport avec le full object, le problème c'est que chaque extension est développée par une équipe de codeur différent, d'ou les différences de logiques et de conventions. $string->toUpper je vois pas tellement l'interêt d'avoir un objet instancié pour un type m'enfin si ça t'amuse voila:

class string {
	static public function toUpper($var) {
		$result = '';
		if(gettype($var) == 'string') {
			$result = strtoupper($var);
		}
		return $result;
	}
}

Notes que c'est même mieux que ce que tu veux parce que tu peux l'utiliser en static et pas te trainer toute la lourdeur supplémentaire d'un objet...

sans la mettre en static, un trait utilitaire et tu l'utilise dans toute tes classes comme si c'était natif ?


oui oui je sort

@+