Discussion :

[Spartacusply]

Le soucis avec les arrays c'est que c'est pas précis, ça peut contenir n'importe quoi.
A chaque fois que tu utilises un array en paramètre dans une fonction en php, n'importe quel array va passer, alors que toi tu es en droit d'attendre un array possédant des clefs ou des valeurs bien précises.
Pour contrer cela, d'autres langages (comme C# ou Java), on la généricité, c'est à dire qu'un array ne va pouvoir contenir des valeurs que d'un type donné (mais bon en php étant donné que y a même pas de typage... ).

De plus, nativement un array est la seule collection disponible en php : tu veux ranger plusieurs objets ensemble, ben t'as pas le choix, faut que t'utilises en array. Dans d'autres languages, il existe bien d'autre Collection, qui sont parfois bien plus pratiques à manipuler que des arrays (tels que les lists, les Hash, les Trees...).

[Gugelhupf]

Les arrays en PHP sont des objets fourre-tout et les casts se font n'importe comment :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<?php
 
$a = ["zero" => 0, "1" => 1.5, 2.5 => new DateTime()];
 
foreach($a as $key => $val) {
    var_dump($key, $val);	
}

Affiche (avec ajout de commentaire perso) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
string(4) "zero"
int(0)
int(1) // FAUX => En théorie c'est un string
float(1.5)
int(2) // FAUT => En théorie c'est un float
object(DateTime)#1 (3) {
  ["date"]=>
  string(26) "2015-06-03 11:13:08.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}

[RyzenOC]

Le soucis avec les arrays c'est que c'est pas précis, ça peut contenir n'importe quoi.

C'est comme en python avec les list.

Je comprend ton point de vue, moi je considère que c'est plus un "avantage", en effet sa permet d'avoir du code très flexible.
Je trouve cela dommage qu'en java les list ne soient comme cela.


Selon moi il faut pouvoir imposer (de manière optionnel) un type particulier dans une list/tableau.
Si je veut mettre n'importe quoi dans un array, par exemple pour enregistrer les données d'un formulaire (chaine de caractere,entier, date...) c'est très pratique, par contre si je veut mettre que des booleen, que des entier, la effectivement c'est plus embêtant.

Visiblement, php7 devrait offrir ces flexibilité. Espérons que le typage reste toujours optionnel.

[Gugelhupf]

Je comprend ton point de vue, moi je considère que c'est plus un "avantage", en effet sa permet d'avoir du code très flexible.
Je trouve cela dommage qu'en java les list ne soient comme cela.

Si tu considères cela comme un avantage, tu peux faire les mêmes cochonneries en Java, exemple du code précédent Java-ifié (test ici) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Map<Object, Object> m = new LinkedHashMap<>();
m.put("zero", 0);
m.put("1", 1.5);
m.put(2.5, new Date());
 
for(Map.Entry<Object, Object> e : m.entrySet()){
    System.out.println(e.getKey().getClass().getName() + "(" + e.getKey() + ")");
    System.out.println(e.getValue().getClass().getName() + "(" + e.getValue() + ")");
}

Affiche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
java.lang.String(zero)
java.lang.Integer(0)
java.lang.String(1)
java.lang.Double(1.5)
java.lang.Double(2.5)
java.util.Date(Thu Oct 19 07:19:28 GMT 2000)

=> L' "avantage" c'est que le type est respecté.

[Tsilefy]

C'est comme en python avec les list.

Je comprend ton point de vue, moi je considère que c'est plus un "avantage", en effet sa permet d'avoir du code très flexible.
Je trouve cela dommage qu'en java les list ne soient comme cela.


Selon moi il faut pouvoir imposer (de manière optionnel) un type particulier dans une list/tableau.
Si je veut mettre n'importe quoi dans un array, par exemple pour enregistrer les données d'un formulaire (chaine de caractere,entier, date...) c'est très pratique, par contre si je veut mettre que des booleen, que des entier, la effectivement c'est plus embêtant.

Visiblement, php7 devrait offrir ces flexibilité. Espérons que le typage reste toujours optionnel.

Hack propose des génériques. Il y a eu une rfc arrayof (une sorte de générique) proposée pour PHP 5.6 mais elle a été rejetée. Une nouvelle rfc sur les génériques cible 7.1, mais est pour l'instant en statut de brouillon.

[Spartacusply]

Les arrays en PHP sont des objets fourre-tout et les casts se font n'importe comment :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<?php
 
$a = ["zero" => 0, "1" => 1.5, 2.5 => new DateTime()];
 
foreach($a as $key => $val) {
    var_dump($key, $val);	
}

Affiche (avec ajout de commentaire perso) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
string(4) "zero"
int(0)
int(1) // FAUX => En théorie c'est un string
float(1.5)
int(2) // FAUT => En théorie c'est un float
object(DateTime)#1 (3) {
  ["date"]=>
  string(26) "2015-06-03 11:13:08.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}

Pour moi c'est un argument non valable, il est clairement spécifié dans la doc que les clefs ne peuvent être que des entiers ou des chaînes de caractères, et la logique de comment ils seront castés (qui elle, n'est pas débile). http://php.net/manual/fr/language.ty...tax.array-func
De plus, les exemples comme ça sont trompeurs car dans un vrai programme si tu arrives à avoir un tableau comme ça à un moment donné, c'est que t'es vraiment un grand grand branquignole. C'est complètement idem pour ton exemple avec le Java, faire une Map de <Object,Object> n'a aucun sens.

Je comprend ton point de vue, moi je considère que c'est plus un "avantage", en effet sa permet d'avoir du code très flexible.

Expliquer qu'il y a des inconvénients par rapport à d'autres langages ne veut pas dire que je n'y trouve aucun avantage
Je ne dis pas que l'un est le mal, l'autre est le bien, juste comment ça marche et qu'elles sont les distinctions par rapport aux langages fortement typés et qu'ils faut donc faire avec.

[Tsilefy]

Pardonnez mon ignorance mais quel est le souci avec les Arrays?

Pour ajouter à ce qui a été dit, un array cache les dépendances de ta classe. L'utilisateur ne peut pas deviner quels sont ces dépendances en regardant simplement l'interface (la signature des méthodes), il faut qu'il trifouille dans le code pour le deviner.

Ce qui ne veut pas dire que les arrays sont à éviter, au contraire. Les arrays en tant que structure de données sont l'une des forces de PHP. Il faut juste limiter autant que possible leur utilisation pour passer des paramètres.

[miky55]

Je t'invite sérieusement à te renseigner sur le sujet, plutôt que comparer des carottes à des choux fleurs ...
Enfin, .Net ne tourne pas dans une VM ... A moins que tu considères que la CLR soit une VM, mais là, je ne peux rien faire pour toi.
Je ne vais pas commencer à expliquer ce qu'est un langage managé ...
Concernant le code en natif, rebelote : renseignes toi ...

Je crois que pour le coup tu ferais bien de te renseigner toi même: la CLR est bien une VM tout comme la JVM, que ça te plaise ou non... Je suis bien placé pour parler, j'ai fait pas mal de reversing .net et je peux te dire le code MSIL est beaucoup plus proche du code source que d'un exécutable, il est d'ailleurs totalement réversible, tu retrouves tout jusqu'aux noms des variables et méthodes.En se sens les langages interprétés et managés sont très proche dans leur fonctionnement contrairement aux langages compilés... Ton compilé 2 fois ne veut strictement rien dire car finalement tu n'as pas réellement un binaire avec des instructions procos...

Pour ce qui est su reste tu as raison si on veut comparer php à .net il est clairement souhaitable de comparer php également avec framework. Mais dans tous les cas les applications réalisés en asp net pourraient parfaitement être réalisées en php/framework et vice versa. Donc je persiste à dire que comparer les deux n'est pas ridicule du tout

[rawsrc]

Aparté :

Pour la problématique des clés des tableaux en PHP, j'avais eu besoin un jour de manipuler un tableau différenciant les types de données au niveau des clés et permettant des clés de type float sans auto-casting.
J'avais posté sur DVP (en 2011) un bout de code à ce sujet.

Les benchmarks sont comme les promesses en politique, ils n'engagent que ceux qui y croient...
Je dois reconnaître quand même que PHP 7 s'annonce sous de bons auspices, j'avais testé y a quelques temps le noyau PHP7ng et effectivement le gain de perfs est impressionnant sans même aucun bidouillage autour.

Personnellement, le typage facultatif (plus ou moins fort) est un vrai plus et son utilisation dans les noyaux des composants et/ou des frameworks vous obligera à transtyper le plus tôt possible les données à traiter et à intercepter le cas échéant les erreurs qui vont avec sans plonger trop profondément dans les entrailles du code. Gros plus pour certains aspects au niveau de la sécurité. Fini les tests éparpillés et redondants un peu partout dans le code : chouette

[stailer]

micky55 : "Mais dans tous les cas les applications réalisés en asp net pourraient parfaitement être réalisées en php/framework et vice versa. Donc je persiste à dire que comparer les deux n'est pas ridicule du tout"

+1, c'est exactement ce que je disais plus haut.. Combien de fois en ASP.NET MVC je me suis dit : "Ah tiens avec le ZF ça irait plus vite, c'est mieux fait !" mais aussi l'inverse avec le ZF, nombre de fois j'ai pu me dire : "Avec ASP.NET MVC tout est objet et je ne galèrerais pas à voir toutes les propriétés de ma variable car à ce moment précis dans l'appli le cast est pas possible" (c'est un exemple parmi d'autres, avec utilisation d'ORM notamment).

Aucun des 2 frameworks me ferait abandonner l'autre.

[Nicam]

+1, c'est exactement ce que je disais plus haut.. Combien de fois en ASP.NET MVC je me suis dit : "Ah tiens avec le ZF ça irait plus vite, c'est mieux fait !" mais aussi l'inverse avec le ZF, nombre de fois j'ai pu me dire : "Avec ASP.NET MVC tout est objet et je ne galèrerais pas à voir toutes les propriétés de ma variable car à ce moment précis dans l'appli le cast est pas possible" (c'est un exemple parmi d'autres, avec utilisation d'ORM notamment).

Aucun des 2 frameworks me ferait abandonner l'autre.

A ce jeu là, tu peux tout faire dans tous les langages. Pourquoi pas faire du Perl, du C voir même de l'assembleur ?
In finé, tu peux tout faire avec tous les langages. C'est pas pour cela qu'il est naturel de les comparer.
Surtout lorsque l'un est type et pas forcement l'autre.
Surtout que pour faire vite, webform est quand même super bien (Bon, ok, tu subies le code généré par la Framework .Net, et tu t'assoies sur les tests unitaires, mais dans 70 % des cas, c'est suffisant, et largement plus rapide à développer).

Apres, je te rejoins, c'est vraiment une question de besoin, ET d'habitude.
Ce ne sont pas deux technos qui s'opposent.

[Nicam]

... je peux te dire le code MSIL est beaucoup plus proche du code source que d'un exécutable, il est d'ailleurs totalement réversible, tu retrouves tout jusqu'aux noms des variables et méthodes.En se sens les langages interprétés et managés sont très proche dans leur fonctionnement contrairement aux langages compilés... Ton compilé 2 fois ne veut strictement rien dire car finalement tu n'as pas réellement un binaire avec des instructions procos...

Mais je n'ai jamais dis le contraire MSIL ressemble quand même largement plus à de l'assembleur qu'a du C#, faut pas déconner non plus
Par contre, dans ton MSIL, tu as aucune reference à la partie hardware de ta machine hote hein C'est là qu'on parle de "VM" ...

Alors après, on peut aisément débattre sur ce qu'est une VM.
De mon point de vue, c'est un systeme qui te permet d'executer un bout de code indépendamment de ton système hote (là, on est dans le cas de Java qui est fait pour ca).
Etant donné que la CLR n’exécute pas de code MSIL (parce qu'il le compile une deuxième fois en langage machine, donc uniquement exécutable sur la machine), on ne peut plus parler de VM.

Pour ce qui est su reste tu as raison si on veut comparer php à .net il est clairement souhaitable de comparer php également avec framework. Mais dans tous les cas les applications réalisés en asp net pourraient parfaitement être réalisées en php/framework et vice versa. Donc je persiste à dire que comparer les deux n'est pas ridicule du tout

Oui et Non, car tu compares un eco système à un langage.
L'avantage d'ASP.net est que le framework est développé par MS lui même, et donc qu'il est parfaitement homogène.
Encore une fois, sans dire que PHP est une mauvaise plateforme (je serais menteur), je trouve qu'il est plus pratique d'aborder la technologie .Net car elle me semble plus complète de base. Juste un exemple, MS fourni son ORM, ce qui n'est pas le cas de PHP.
Tu as aussi un mode d'accès au données déconnecté (ADO.net), en plus du mode connecté (OleDb).
La gestion du cache (pour des applications ASP.net) est directement incluse dans le framework de base, etc etc etc ...

Et puis, en PHP, les possibilités, le style de dev est directement dépendant du framework que tu utilises. Et ils sont assez inégaux (Tu ne procèdes pas de la même manière sur Cake que sur Zend ou encore Synfony). En ASP.Net, tu ne te pose pas vraiment la question, et tu beneficies directement de l'infra-full MS.

Je n'arrive pas à comparer Php and co à .Net.
Le modèle le plus proche de .Net reste J2SE ou JEE.

[miky55]

Et puis, en PHP, les possibilités, le style de dev est directement dépendant du framework que tu utilises. Et ils sont assez inégaux (Tu ne procèdes pas de la même manière sur Cake que sur Zend ou encore Synfony). En ASP.Net, tu ne te pose pas vraiment la question, et tu beneficies directement de l'infra-full MS.

Je n'arrive pas à comparer Php and co à .Net.
Le modèle le plus proche de .Net reste J2SE ou JEE.

Je pense qu'on se comprend sans être d'accord donc inutile de s’éterniser dans se débat. Ce que je voulais comparer à la base c'est les performances, comme le poste qui à lancé cette conversation. Ça ne me dérangerai pas non plus de comparer php python et ruby a .net et jee en terme de perf voir meme pk pas cpp et cgi. À la base le test était sur un algo bien précis sans accès bdd ni rien du tout, donc commencer à parler d'orm etc n'a pas vraiment de sens dans ce contexte. Donc ils auraient très bien pu réécrire cela en asp .net (sans instancier aucune classe du framework donc en c# si tu préfère).

PS: D'ailleurs ils ont même mis java et gcc dans le bench ( si c'est bien celui-ci posté un peu plus haut par un membre https://gist.github.com/dstogov/12323ad13d3240aee8f1 )

[Fnux.]

Ça ne me dérangerai pas non plus de comparer php python et ruby a .net et jee en terme de perf voir meme pk pas cpp et cgi. À la base le test était sur un algo bien précis sans accès bdd ni rien du tout...
D'ailleurs ils ont même mis java et gcc dans le bench ( si c'est bien celui-ci posté un peu plus haut par un membre https://gist.github.com/dstogov/12323ad13d3240aee8f1 )

Pour en revenir à l'article en question, celui-ci s'appuie sur un benchmark que personne ne peut contester dans la mesure où il n'est fait aucune mention ni de l'environnement de test, ni de l'outil utilisé pour faire ces tests.

Bref, ce ne sont que des graphiques incontrôlables publiés par ZEND dans une press release !

C'est de la comware, pour ne pas dire du vaporware !

Maintenant, si ZEND les a bien pendues, qu'il communique l'intégralité des données reproduisibles par tout un chacun et l'on verra bien qui est "Raoul".

Comparer une version béta de PHP version 7 sur une seule fonction par rapport à des versions antédiluviennes d'autres langages est une preuve manifeste de leur mauvaise foi.

Et d'ailleurs, qui affiche des images de Mandelbrot (qui plus est en mode caractère) sur son site web ?

A part nous prendre pour des lapins de trois semaines... je n'en vois strictement aucun intérêt.

Mais je dis ça, je ne dis rien !

[jojosbiz]

Haaaa, ça tourne en débat sur les framework, j'adore.

Donc je vais en profiter pour me faire du bien et dire que les framework pour PHP style Symphony, Laravel, etc... ne servent à rien !!! (J'ai déjà utilisé Laravel pour info, qui est sensé être le framework "à la mode").

Je sais que tout le monde se fout de mon avis et qu'il est extrêmement minoritaire, mais il faut savoir se faire du bien de temps en temps

L'image du bulldozer pour écraser une mouche est tout à fait appropriée.


Sinon, j’attends cette version de PHP 7 avec impatience, tout cela m'a l'air vraiment intéressant.

[Tsilefy]

Haaaa, ça tourne en débat sur les framework, j'adore.

Donc je vais en profiter pour me faire du bien et dire que les framework pour PHP style Symphony, Laravel, etc... ne servent à rien !!! (J'ai déjà utilisé Laravel pour info, qui est sensé être le framework "à la mode").

Je sais que tout le monde se fout de mon avis et qu'il est extrêmement minoritaire, mais il faut savoir se faire du bien de temps en temps

L'image du bulldozer pour écraser une mouche est tout à fait appropriée.

Sans donner mon avis sur cette question toujours sujette à polémique (prochains sujets: pour ou contre les ORMs? Pour ou contre le typage strict?), tu remarqueras que le développement PHP s'oriente de plus en plus vers l'utilisation de composants plutôt que de full-stack frameworks.

[jojosbiz]

Sans donner mon avis sur cette question toujours sujette à polémique (prochains sujets: pour ou contre les ORMs? Pour ou contre le typage strict?), tu remarqueras que le développement PHP s'oriente de plus en plus vers l'utilisation de composants plutôt que de full-stack frameworks.

Et c'est tant mieux !

Je ne suis pas contre l'utilisation de composants pour se faciliter la vie et je remercie toujours ceux qui les font.

Mais quand je vois "framework" et "PHP" (ou "Javascript", c'est la même chose à mes yeux) dans la même phrase, j'ai la tension qui monte...
Et je trouve qu'on les voit beaucoup trop ces derniers temps.


PS : je suis contre les ORM
Pour le typage strict je n'ai pas vraiment d'avis, l'un ou l'autre ne me gêne pas.

[Tsilefy]

Et c'est tant mieux !

Je ne suis pas contre l'utilisation de composants pour se faciliter la vie et je remercie toujours ceux qui les font.

Mais quand je vois "framework" et "PHP" (ou "Javascript", c'est la même chose à mes yeux) dans la même phrase, j'ai la tension qui monte...
Et je trouve qu'on les voit beaucoup trop ces derniers temps.


PS : je suis contre les ORM
Pour le typage strict je n'ai pas vraiment d'avis, l'un ou l'autre ne me gêne pas.

Même les partisans des ORMs se déchirent entre Data Mapper ou Active Record comme Dieu Unique

Pour revenir au sujet, on peut aussi considérer une architecture basée sur des composants comme étant un Framework customisé. Symfony ou Laravel proposent la même chose, sauf qu'ils font le choix des composants de base pour toi, et écrivent en plus la "colle" qui tient l'ensemble à ta place, mais échange tu dois te plier à leurs rites (pour rester dans l'analogie du Dieu Unique). J'ai une préférence pour les composants, mais je suis actuellement confronté au problématique du choix technologique pour une équipe où il faut trouver un langage commun et une direction très vite, et ma conclusion est que l'utilisation d'un Framework permet de simplifier la communication (surtout s'il y a de nouveaux arrivants en cours de route) et d'éviter la friction sur la méthode à suivre: on suit la Voie du framework, un point c'est tout.

C'est qui m'effraie en js c'est que le framework du jour semble changer tous les six mois, et encore je parle uniquement côté front-end.

[jojosbiz]

Même les partisans des ORMs se déchirent entre Data Mapper ou Active Record comme Dieu Unique

Pour revenir au sujet, on peut aussi considérer une architecture basée sur des composants comme étant un Framework customisé. Symfony ou Laravel proposent la même chose, sauf qu'ils font le choix des composants de base pour toi, et écrivent en plus la "colle" qui tient l'ensemble à ta place, mais échange tu dois te plier à leurs rites (pour rester dans l'analogie du Dieu Unique). J'ai une préférence pour les composants, mais je suis actuellement confronté au problématique du choix technologique pour une équipe où il faut trouver un langage commun et une direction très vite, et ma conclusion est que l'utilisation d'un Framework permet de simplifier la communication (surtout s'il y a de nouveaux arrivants en cours de route) et d'éviter la friction sur la méthode à suivre: on suit la Voie du framework, un point c'est tout.

C'est qui m'effraie en js c'est que le framework du jour semble changer tous les six mois, et encore je parle uniquement côté front-end.

Justement, c'est ce qui me dérange dans les framework, cette obligation d'apprendre une nouvelle syntaxe.

Apprendre de nouvelles choses ne me dérange pas, ça m'arrive tous les jours ou presque, mais quand c'est vraiment nouveau !

Faire exactement la même chose que ce que je sais faire, en plus dans le même langage que je maitrise depuis maintenant 13 ans (environ), avec lequel je n'ai jamais eu de problème pour faire tout ce qu'on m'a demandé jusque là (et j'ai fait un gros tas de choses différentes), mais d'une façon différente tout ça parce que c'est à "la mode" : c'est ça que je trouve débile et ridicule.

Et l'argument de "c'est plus simple pour ceux qui arrivent ou pour se relire" est aussi ridicule à mes yeux.
Quand ce n'est pas toi qui a écrit le code, tu mets toujours du temps à le comprendre.
Quand tu es nouveau et que tu ne connais pas le framework ou le langage, tu mets du temps à l'apprendre.

Dans ma boite, le dernier projet a été fait avec Laravel, le prochain le sera aussi.
Je trouve ça d'une inutilité consternante mais ce n'est pas moi qui décide...
Et sur les 4 dev qui vont y toucher, 1 seul (celui qui a décidé de l'utiliser) arrive à se débrouiller avec, pour les autres c'est comme recommencer de 0 alors que nous saurions développer tout le projet sans Laravel sans aucun problème.

[Nicam]

@Stailer : Sauf erreur de ma part, je n'ai pas remis en cause ni totalement, ni partiellement la techno PHP.
J'ai dis que je n'aimais pas PHP pour une raison précise, et encore, j'ai ajouté que c'est l'utilisation qui en est faite que je n'aime pas.
Et ca ne se limite malheureusement pas qu'aux sous couches de Zend. Il y a des tonnes d'applications PHP qui utilisent encore trop de paramètres sous forme d'array.
Php est une très bonne techno (que j'ai pratiqué aussi en tant que développeur et en tant que chef de projet technique).
Je me sens juste plus à l'aise avec des langage comme Java et C# dans des envirronement JEE ou .Net. C'est une question de gout,et ca n'engage que moi.

@Gugelhupf : C'était facile, je le reconnais.
Mais c'est un peu plus complexe que cela malgré tout. On compare la CLR à une VM car l'un de ses rôle est de convertir des codes en differents langages (C#, VB, etc ...) en langage intermédiaire : le CIL (un peu comme Java et son bytecode). Sauf qu'ensuite, avant exécution, ce code intermédiaire est compilé en langage machine. Alors que Java interprète son bytecode, la CLR le compile en langage machine.
On est plus du tout en condition de VM comme en Java. A l’exécution, la CLR gère l’exécution du code (accès mémoire, sécurité, etc ...) mais n’agis pas comme un VM qui est étanche. Le code exécute est bien spécifique à l'os et à la machine qui l’exécute. C'est pour cela que je refuse d'appeler ca une VM.
La CLR n'abstrait absolument pas les ressource physiques de la machine exécutante. Elle est là pour contrôler l’exécution, via le JIT.