Discussion :

[stailer]

Code :

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

public static string AjouteCool(this string s) { return s + " cool"; }'.

Ce n'est pas un paramètre car au final tu fais bien :
maChaine.AjouteCool() sans paramètre ! c'est une extension à string.

On est des milliers à avoir vu l'intérêt tout de suite.
Par exemple : tu peux te faire des extensions à string pour dire que tu veux proposer une méthode qui ne renvoie que les 10 premiers mots (seul 10 sera en paramètre, pas la chaine)...
Tu peux faire une extension à DateTime pour te renvoyer une date dans un format exotique sans avoir à le spécifier (aucun paramètre dans ce cas, pas même la date).

Récémment les méthodes d'extenions m'ont permis de faire des extend à la suite Kendo UI ASP.NET MVC. J'ai pu crée des composants custom sans étendre de classe. Mais là on est dans du spécifique.

Pour revenir à de la simplicité, on peut également imaginer une extension à float mais qui va retourner un string pour retourner un format de float spécifique : de 10.5 on peut avoir ToEuro();

Code :

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

1
2
3
4
5
 
float MonFloat = 10.5;
MonFloat.ToEuro()
 
Retournera : 10,5 €

Donc ça permet de faire des raccourcis très simplement, rangés dans une même classe. OUI tu peux te faire une classe statique mais alors tu auras :

Code :

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

1
2
3
 
float MonFloat = 10.5;
MaClasseStatique.ToEuro(MonFloat);

Ca ajoute une visibilité et une maintenabilité très sympa.

Je te rappelle que l'on parlais au préalable du typage fort vis-à-vis du typage faible. Franchement, je ne voie pas le rapport avec ta démonstration.

Et bien je disais dans mon 1er message, que j'aimais bien ces méthodes d'extensions (comme bcp de dév C#) et qu'en PHP on aurait probablement jamais ça car il est en typage faible.
C'est tout ! Il n'empêche encore un fois que j'adore php...

Là dessus tu es parti sur le fait que mon exemple était "le principe de l'objet" : c'est faux et c'est tout.

Pour moi ça s'arrêtait là mais tu as continué en "m'expliquant la vie" ... En toute logique je me défends.

[Zefling]

Comme tu l'as observé, c'est juste du sucre syntaxique, qui permet d'écrire a.MultiplierParDeux() au lieu de IntExtensions.MultiplierParDeux(a). Dans ce cas précis l'intérêt est limité ; là où ça devient utile, c'est pour chaîner les appels. Ça a été ajouté à C# pour rendre plus pratique l'utilisation de Linq :

Code C# :

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

var result = numbers.Where(x => x > 10).Select(x => x * 2).ToList();

Where, Select et ToList sont des méthodes d'extension. Sans ce mécanisme, il faudrait écrire :

Code C# :

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

var result = Enumerable.ToList(Enumerable.Select(Enumerable.Where(numbers, x => x > 10), x => x * 2));

Ça revient au même, mais c'est beaucoup moins lisible...

Je ne vois pas ce que cette exemple a d'exceptionnel. C'est juste que Where et Select renvoient this, donc tu peux chaîner. Mais peut-être que je me trompe la dernière fois que j'ai touché au C# c'était il y a 6 ans.

Ça me fait penser à ça en PHP (Le plus bizarre sera probablement l’instruction ['ul > li'] pour ceux qui ne font pas de PHP) :

Code PHP :

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

phpQuery::newDocument($html)['ul > li']->addClass('my-new-class')->filter(':last')->addClass('last-li')->toReference(null);

[tomlev]

Je ne vois pas ce que cette exemple a d'exceptionnel. C'est juste que Where et Select renvoient this, donc tu peux chaîner.

Non, ça ne renvoie pas this ; ça renvoie un nouvel objet IEnumerable<int> qui s'occupe de faire le filtrage ou la projection.

(et je ne crois pas avoir dit que c'était exceptionnel...)

[stailer]

@Tomlev : oui je sais bien qu'avec les méthodes d'extensions on peut aller plus loin que mes exemples tout bête

[SurferIX]

Je reprends les nouveautés rapidement :

- Null coalesce operator :

Code :

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

$username = $_GET['user'] ?? 'nobody';

Ok c'est pas mal

- Ce code :

Code :

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

1
2
3
4
5
6
function arraysSum(array ...$arrays): array
{
    return array_map(function(array $array): int {
        return array_sum($array);
    }, $arrays);
}

Sérieusement, lorsque vous allez arriver en entreprise, vous allez devoir comprendre du code comme ça mais en plus compliqué ?

- Spaceship operator (oui oui c'est bien son nom ) :

Code :

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

1
2
3
echo 1 <=> 1; // 0
echo 1 <=> 2; // -1
echo 2 <=> 1; // 1

Même chose. Honnêtement, en pratique, vous allez concrètement "économiser" 2 lignes de code. Mais est-ce que vous trouvez cela plus lisible ?

- Anonymous classes

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?php
interface Logger {
    public function log(string $msg);
}
 
class Application {
    private $logger;
 
    public function getLogger(): Logger {
         return $this->logger;
    }
 
    public function setLogger(Logger $logger) {
         $this->logger = $logger;
    }
}
 
$app = new Application;
$app->setLogger(new class implements Logger {
    public function log(string $msg) {
        echo $msg;
    }
});
 
var_dump($app->getLogger());

C'est simple : j'ai relu ce code plein de fois, et honnêtement : quand vous travaillez dans une équipe de dix développeurs, avec un expert qui peut vous pondre ça, sept "moyens" et deux stagiaires, soyons concrets : pourrez-vous maintenir et comprendre facilement du code comme cela ? Sincèrement ? Sur plusieurs années, avec plusieurs développeurs qui vont y toucher ? Soyons réalistes : c'est inutilisable dans de grosses boites, car trop compliqué, ça va même exactement à l'opposé de la manière dont Php s'est fait connaître...

- Unicode codepoint escape syntax

Code :

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

1
2
3
echo "\u{aa}";
echo "\u{0000aa}";
echo "\u{9999}";

La bonne nouvelle c'est qu'il ont repompé sur Python (qui a ça déjà depuis une dizaine d'années, et sur Javascript). La mauvaise ? C'est que c'est pas exactement la même syntaxe.

- Closure::call()

Code :

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

1
2
3
4
5
6
7
8
9
10
11
<?php
class A {private $x = 1;}
 
// Pre PHP 7 code
$getXCB = function() {return $this->x;};
$getX = $getXCB->bindTo(new A, 'A'); // intermediate closure
echo $getX();
 
// PHP 7+ code
$getX = function() {return $this->x;};
echo $getX->call(new A);

Merci Javascript pour avoir apporté cela. Il y en a qui trouvent que ça améliore le langage, d'autres qui trouveront, comme moi, que ça rajoute juste une possibilité supplémentaire de faire du code encore plus complexe.

- Generator delegation : je ne copie même pas l'exemple tant, déjà rien qu'à un niveau appel + sous appel, il commence à être complexe (alors que par essence même, il est prévu pour faire plus (sinon on peut s'en passer)).

Et encore deux trois.
Bref, en tout et pour tout, Php "s'ouvre", ou, à mon sens, se complexifie inutilement, sans ajouter des fonctionnalités vitales pour moi.
Toujours pas d'héritage multiple. Gestion toujours aussi mauvaise de l'utf8 et unicode (à part le "patch" copié collé de Python/JavaScript).

Rien que cela me pousse encore plus et j'avance en ce sens, vers la migration complète et définitive de tout mon parc vers du Python.
Le jour où Php aura, comme Python, en natif, la totalité de l'aide intégré à l'installeur, la documentation des fonctions appelable via "help(maFonction)", y compris celles qu'on développe...
Ou encore les décorateurs, qui sont autant une idée de génie que c'est pratique...
Ou l'héritage multiple...
Bref Php, pour l'instant, non merci, je ne replongerai dedans que lorsque je n'aurai plus de quoi vivre... en espérant que Python me permette de vivre (j'ai signé un contrat avant hier qui m'assure de vivre sur les six mois à venir, tout Django/Python ).

[rawsrc]

Salut,

Quand on veut se débarrasser de son clébard, on dit qu'il a la rage ...

Code :

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

1
2
3
4
5
6
function arraysSum(array ...$arrays): array
{
    return array_map(function(array $array): int {
        return array_sum($array);
    }, $arrays);
}

Sérieusement, lorsque vous allez arriver en entreprise, vous allez devoir comprendre du code comme ça mais en plus compliqué ?

Très drôle, ce code est équivalent à celui-ci sans le typage :

Code :

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

1
2
3
4
function arraysSum(array ...$arrays)
{
    return array_map('array_sum', $arrays);
}

- Spaceship operator (oui oui c'est bien son nom ) :

Code :

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

1
2
3
echo 1 <=> 1; // 0
echo 1 <=> 2; // -1
echo 2 <=> 1; // 1

Même chose. Honnêtement, en pratique, vous allez concrètement "économiser" 2 lignes de code. Mais est-ce que vous trouvez cela plus lisible ?

bien sûr que cela doit être utilisé, cela raccourcit l'écriture des fonctions de comparaisons dans les tris perso.
Je ne te parle même pas du raccourcissement du code et le gain en lisibilité pour les comparaisons de tableaux...
En php, le tableau est roi

- Anonymous classes

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?php
interface Logger {
    public function log(string $msg);
}
 
class Application {
    private $logger;
 
    public function getLogger(): Logger {
         return $this->logger;
    }
 
    public function setLogger(Logger $logger) {
         $this->logger = $logger;
    }
}
 
$app = new Application;
$app->setLogger(new class implements Logger {
    public function log(string $msg) {
        echo $msg;
    }
});
 
var_dump($app->getLogger());

C'est simple : j'ai relu ce code plein de fois, et honnêtement : quand vous travaillez dans une équipe de dix développeurs, avec un expert qui peut vous pondre ça, sept "moyens" et deux stagiaires, soyons concrets : pourrez-vous maintenir et comprendre facilement du code comme cela ? Sincèrement ? Sur plusieurs années, avec plusieurs développeurs qui vont y toucher ? Soyons réalistes : c'est inutilisable dans de grosses boites, car trop compliqué, ça va même exactement à l'opposé de la manière dont Php s'est fait connaître...

L'approche php est cohérente, les classes anonymes sont proches par analogie (avec un fonctionnement spécifique aux classes bien entendu) au déréférencement des arrays et des strings du php 5.5
Tu créés des classes à la volée au besoin sans avoir à les "préparer" avant. Va voir du côté de C# et de java en la matière...

- Unicode codepoint escape syntax

Code :

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

1
2
3
echo "\u{aa}";
echo "\u{0000aa}";
echo "\u{9999}";

La bonne nouvelle c'est qu'il ont repompé sur Python (qui a ça déjà depuis une dizaine d'années, et sur Javascript). La mauvaise ? C'est que c'est pas exactement la même syntaxe.

je te l'accorde : l'unicode et le php c'est toujours de l'à peu près

- Closure::call()

Code :

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

1
2
3
4
5
6
7
8
9
10
11
<?php
class A {private $x = 1;}
 
// Pre PHP 7 code
$getXCB = function() {return $this->x;};
$getX = $getXCB->bindTo(new A, 'A'); // intermediate closure
echo $getX();
 
// PHP 7+ code
$getX = function() {return $this->x;};
echo $getX->call(new A);

Merci Javascript pour avoir apporté cela. Il y en a qui trouvent que ça améliore le langage, d'autres qui trouveront, comme moi, que ça rajoute juste une possibilité supplémentaire de faire du code encore plus complexe.

rien d'extraordinaire : l'injection de contexte. En JS c'est le pain quotidien.

- Generator delegation : je ne copie même pas l'exemple tant, déjà rien qu'à un niveau appel + sous appel, il commence à être complexe (alors que par essence même, il est prévu pour faire plus (sinon on peut s'en passer)).

cette fonctionnalité est intéressante pour ceux qui se cognent massivement des fonctions générateurs (yield), c'est à dire peu de gens. Mais si ça leur simplifie la vie, personne ne va s'en plaindre. Sans compter que l'implémentation en natif de n'importe quelle optimisation est toujours bien meilleure à la bidouille sur un coin de table. Lis la RFC pour cette fonction et vois par toi même ce que cela supprime comme code...
A ton niveau, tu n'en comprends peut-être pas l'utilité mais si tu regardes les votes de l'équipe c'est du 100% pour. Après c'est comme souvent, c'est disponible au sein du langage, mais libre à toi de l'utiliser ou pas selon tes besoins.
D'ailleurs, si tu connaissais mieux python , tu aurais vu que cette fonctionnalité a été implémentée dans la version 3.3 du langage... Lol

Et encore deux trois.
Bref, en tout et pour tout, Php "s'ouvre", ou, à mon sens, se complexifie inutilement, sans ajouter des fonctionnalités vitales pour moi.
Toujours pas d'héritage multiple. Gestion toujours aussi mauvaise de l'utf8 et unicode (à part le "patch" copié collé de Python/JavaScript).

Rien que cela me pousse encore plus et j'avance en ce sens, vers la migration complète et définitive de tout mon parc vers du Python.
Le jour où Php aura, comme Python, en natif, la totalité de l'aide intégré à l'installeur, la documentation des fonctions appelable via "help(maFonction)", y compris celles qu'on développe...
Ou encore les décorateurs, qui sont autant une idée de génie que c'est pratique...
Ou l'héritage multiple...
Bref Php, pour l'instant, non merci, je ne replongerai dedans que lorsque je n'aurai plus de quoi vivre... en espérant que Python me permette de vivre (j'ai signé un contrat avant hier qui m'assure de vivre sur les six mois à venir, tout Django/Python ).

Tu viens de découvrir que les langages se pompaient allègrement les uns les autres ou c'est juste pour affirmer avec force ton nouvel amour pour python ?

Pour ce qui est des arguments concernant la doc à l'heure de l'internet...
L'héritage multiple c'est un concept délicat, mais je pense qu'avec les interfaces, l'héritage simple et les traits, y a déjà de quoi combler une tonne de besoins.

Et pour finir : en entreprise, les codeurs doivent quand même avoir un niveau qui tient la route, tu n'en feras pas d'une équipe de clampins, des cadors sans un investissement important dans la formation aux nouveautés de n'importe quel langage.

[SurferIX]

D'ailleurs, si tu connaissais mieux python , tu aurais vu que cette fonctionnalité a été implémentée dans la version 3.3 du langage... Lol

Tu as entièrement raison : Php n'a que trois ans de retard sur Python - en supposant que la 7 en release sorte cette année , LOL³²

Tu viens de découvrir que les langages se pompaient allègrement les uns les autres ou c'est juste pour affirmer avec force ton nouvel amour pour python ?

Si tu savais un peu mieux à qui tu parle, tu n'emploierais pas ce ton inutilement hautain... Au même titre que j'ai une très grosse dent depuis plus d'une dizaine d'année contre Windows vs Linux, qui m'a fait perdre des mois de travail entiers par sa mauvaise conception (serveur haute performance utilisant les sockets asynchrone, le coeur même du fonctionnement de windows, lien ici sur la fonction coeur qui m'a fait perdre presque un an de boulot - j'ai refait le même en une semaine sur Linux), et que j'explique systématiquement à tous les gens que je rencontre pourquoi et comment j'ai perdu du temps, ce qui est indéniable, je viens de vivre en deux mois la même chose avec Php et Python.

Pour ce qui est des arguments concernant la doc à l'heure de l'internet...

Tu n'as pas (non plus) d'expérience dans de l'embarqué ou sur le RaspberryPi j'imagine, sinon là aussi tu n'emploierais pas ce ton inutilement hautain...

L'héritage multiple c'est un concept délicat, mais je pense qu'avec les interfaces, l'héritage simple et les traits, y a déjà de quoi combler une tonne de besoins.

Donc tu pense vraiment que les interfaces, l'héritage simple et l'immondice bâtarde que sont les traits, on comble la lacune énorme qu'est l'héritage multiple ? Manque de pratique intense, je suppose.

Tu créés des classes à la volée au besoin sans avoir à les "préparer" avant.

Ton discours semble dire que c'est pratique. Si c'est le cas, je te laisse avoir un peu plus d'expérience avec d'autres développeurs, et revenir dans quelques années pour voir si tu tiens toujours le même discours, ou si tu as banni des pratiques qui pourraient être bien (j'insiste bien sur ce terme), mais qui au final, montrent qu'elle ne sont pas maintenables sur du long terme et / ou / de grosses applications métier.

Et pour finir : en entreprise, les codeurs doivent quand même avoir un niveau qui tient la route, tu n'en feras pas d'une équipe de clampins, des cadors sans un investissement important dans la formation aux nouveautés de n'importe quel langage.

Tu ne tiendras pas ce langage lorsque tu auras plus d'expérience, parce que j'espère que c'est le manque d'expérience qui t'as fait tenir le discours que je viens de lire...

[Tsilefy]

Tu n'as pas (non plus) d'expérience dans de l'embarqué ou sur le RaspberryPi j'imagine

Si tu utilises PHP dans l'embarqué ou Raspberry Pi, ce n'est pas exactment un choix pertinent.

Donc tu pense vraiment que les interfaces, l'héritage simple et l'immondice bâtarde que sont les traits, on comble la lacune énorme qu'est l'héritage multiple ? Manque de pratique intense, je suppose.

La pratique en OOP m'a fait presque quasiment abandonner l'héritage, y compris l'héritage simple, au profit de la composition et les interfaces à l'exception des cas les plus basiques. Peux-tu me citer des cas résolus par l'héritage multiple que je ne peux pas résoudre par la composition? Ça doit exister, mais en nombre très infime...

Classes anonymes: l'exemple est mauvais je trouve. Ce genre de technique a sa place dans les méthodes privées d'une classe, pas dans une API publique, et encore moins appelé directement comme ça. Mais c'est comme les lambda/closures: c'est très utile quand on n'en abuse pas et qu'on ne fait pas des classes anonymes de 50 lignes. Ets-ce que tu as la même objection pour les closures, qui ont la même philosophie?
Après, je n'ai pas regardé en détail l'implémentation de PHP, qui parfois peut être "bizarre" (çad jamais comme les autres langages).

Sinon, ton discours est fréquent chez tous ceux qui viennent de découvrir quelque chose et qui ont les yeux brillent. C'est la phase d'euphorie, comme en amour :-) J'ai lu les mêmes choses quand rails est apparu, quand node.js est apparu, quand Laravel est apparu... Qu'est-ce que ça va être quand tu découvriras Haskell! (moi j'ai eu l'impression de découvrir une nouvelle galaxie!)

Cela dit, Python est évidemment génial, mais tu ne peux pas comparer Django/Python à PHP. C'est comme ceux qui comparent Rails et PHP: compare Django à Symfony, Laravel etc...

[SurferIX]

Bon on fait du hors sujet.

Sinon, ton discours est fréquent chez tous ceux qui viennent de découvrir quelque chose et qui ont les yeux brillent.

Oui j'ai connu ça il y a quinze ans, lorsque je débutais en informatique et que je découvrais Delphi, puis Php, puis Photoshop, puis Imagine sur Amiga, puis...
Bref après les grands amours le calme plat. Depuis je n'ai tenu que deux fois ce discours en 12 ans : lorsque j'ai découvert Unity il y a un an et enfin depuis que je fais du Python....
Sachant que j'ai pratiqué intensivement pas mal d'autres langages sur le plan professionnel et en équipe (C, C++, JavaScript + NodeJS et LUA)
J'insiste sur le fait que quand j'en parle ça a une signification particulière, c'est vraiment qu'il y a quelque chose de plus que la simple découverte.

Peux-tu me citer des cas résolus par l'héritage multiple que je ne peux pas résoudre par la composition

Le problème n'est pas là !! Ce n'est pas dans le fait que tu puisse résoudre les problèmes, le vrai problème est comment tu les résous.
Et faire de la composition au lieu de l'héritage multiple, ça fonctionne, mais c'est plus dur à maintenir.
Et je maintiens mon discours : Php ne permet pas de faire de grosses applications faciles à maintenir, et les évolutions ne l'aident pas en ce sens non plus, mon discours n'est pas plus compliqué ni méchant que ça, avec la petite idée en plus, qui est à mon sens constructive : essayez Python et si vous faites du MVC avec n'importe quel outil en Php, essayez Python + Django.

...tu ne peux pas comparer Django/Python à PHP. C'est comme ceux qui comparent Rails et PHP: compare Django à Symfony, Laravel etc...

wtf ? On ne peut pas comparer Django/Python à Symfony/Php ni Laravel/Php ni FuelPhp/Php ni CakePhp/Php ni...
On ne peut pas comparer des outils dont les objectifs sont les mêmes, les structures principalement les mêmes et les résultats obtenus les mêmes (sites Web) ?

Pour terminer cela n'est pas moi qui le dit, c'est ici même sur developpez.com : meilleurs langages en 2015 :
- le plus demandé en mobile : Python devant Php
- le plus en forte croissance : Python devant Php
- le plus demandé par les employeurs : Python devant Php (Php prend une grosse gifle ici, position 7 contre 3 pour Python)
- les langages les plus utilisés pour développer du Web : Python devant Php (oui à l'international c'est ainsi. En France on a quelques années de retard, on pense toujours que Php rocks, mais on va se réveiller...)
- les langages de développement d’applications d’entreprise, de bureau et scientifiques : Python devant Php... ah Php n'existe même pas là

Bref, Php 7 n'apporte vraiment rien qui manque cruellement du point de vue d'une entreprise.

[rawsrc]

Tu as entièrement raison : Php n'a que trois ans de retard sur Python - en supposant que la 7 en release sorte cette année , LOL³²

Bon écoute, tu adores python et c'est tant mieux pour toi, mais ne t'arrange pas avec la réalité et pose toi la question de quels langages python s'est-il inspiré (t'as vu je n'ai pas dit pompé) et quand tu auras la réponse, tu verras le nombre d'années de retard de python... J'ai honte tellement c'est minable d'en arriver à ça.

Si tu savais un peu mieux à qui tu parle, tu n'emploierais pas ce ton inutilement hautain... Au même titre que j'ai une très grosse dent depuis plus d'une dizaine d'année contre Windows vs Linux, qui m'a fait perdre des mois de travail entiers par sa mauvaise conception (serveur haute performance utilisant les sockets asynchrone, le coeur même du fonctionnement de windows, lien ici sur la fonction coeur qui m'a fait perdre presque un an de boulot - j'ai refait le même en une semaine sur Linux), et que j'explique systématiquement à tous les gens que je rencontre pourquoi et comment j'ai perdu du temps, ce qui est indéniable, je viens de vivre en deux mois la même chose avec Php et Python.

Là aussi pour un développeur, raisonner ainsi c'est vraiment débile. Tu jettes le bébé et l'eau du bain avec juste parce qu'il y a un souci d'implémentation d'une fonctionnalité particulière sur une plateforme complète... Redescends sur Terre, les systèmes informatiques sont vastes et complexes, tout ne peut pas être parfait et comme on l'habitude de dire chaque techno a ses forces et ses faiblesses.

Tu n'as pas (non plus) d'expérience dans de l'embarqué ou sur le RaspberryPi j'imagine, sinon là aussi tu n'emploierais pas ce ton inutilement hautain...

En PHP ??
Les seuls que je connaisse qui codent de l'embarqué c'est pour tout ce qui vole et ils utilisent un paquet de langages

Donc tu pense vraiment que les interfaces, l'héritage simple et l'immondice bâtarde que sont les traits, on comble la lacune énorme qu'est l'héritage multiple ? Manque de pratique intense, je suppose.

T'as raison, on va revenir au boulier parce qu'il as un truc qui ne te convient pas.

Ton discours semble dire que c'est pratique. Si c'est le cas, je te laisse avoir un peu plus d'expérience avec d'autres développeurs, et revenir dans quelques années pour voir si tu tiens toujours le même discours, ou si tu as banni des pratiques qui pourraient être bien (j'insiste bien sur ce terme), mais qui au final, montrent qu'elle ne sont pas maintenables sur du long terme et / ou / de grosses applications métier.

Tu ne tiendras pas ce langage lorsque tu auras plus d'expérience, parce que j'espère que c'est le manque d'expérience qui t'as fait tenir le discours que je viens de lire...

Lol

[SurferIX]

Bon écoute, tu adores python et c'est tant mieux pour toi, mais ne t'arrange pas avec la réalité et pose toi la question de quels langages python s'est-il inspiré (t'as vu je n'ai pas dit pompé) et quand tu auras la réponse, tu verras le nombre d'années de retard de python... J'ai honte tellement c'est minable d'en arriver à ça.

J'attends juste une explication claire et honnête du nombre d'années de retard de python, et dans quels domaines.
Je suis sûr que tu es dans l'incapacité de répondre de manière objective sur les manques actuels de Python.

Là aussi pour un développeur, raisonner ainsi c'est vraiment débile. Tu jettes le bébé et l'eau du bain avec juste parce qu'il y a un souci d'implémentation d'une fonctionnalité particulière sur une plateforme complète... Redescends sur Terre, les systèmes informatiques sont vastes et complexes, tout ne peut pas être parfait et comme on l'habitude de dire chaque techno a ses forces et ses faiblesses.

J'ai bossé 6 mois en tant qu'expert Web et les tous les développeurs venaient me demander conseil. J'ai juste une vision objective, et les améliorations de Php ne comblent pas ses lacunes grossières. Mais je constate encore une fois que personne n'est plus aveugle que celui qui ne veut pas voir.

Les seuls que je connaisse qui codent de l'embarqué c'est pour tout ce qui vole

Décidément, vraiment aucune expérience.... et les voitures, les téléphones, portables, les chaines hifi récentes, les... bon laisse tomber.

T'as raison, on va revenir au boulier parce qu'il as un truc qui ne te convient pas. Lol

Si pour toi l'héritage multiple c'est le boulier, alors change de métier, et surtout n'approche pas de moi dans un rayon de 500 km, s'il te plaît.

....minable...débile...lol

Bref. Je me désabonne du fil... encore une personne qui ne supporte pas les critiques, fussent-elles constructives, et qui ne sait argumenter que par les insultes.

[Tsilefy]

- le plus demandé en mobile : Python devant Php
- le plus en forte croissance : Python devant Php
- le plus demandé par les employeurs : Python devant Php (Php prend une grosse gifle ici, position 7 contre 3 pour Python)
- les langages les plus utilisés pour développer du Web : Python devant Php (oui à l'international c'est ainsi. En France on a quelques années de retard, on pense toujours que Php rocks, mais on va se réveiller...)
- les langages de développement d’applications d’entreprise, de bureau et scientifiques : Python devant Php... ah Php n'existe même pas là

Bref, Php 7 n'apporte vraiment rien qui manque cruellement du point de vue d'une entreprise.

je crois que ta nouvelle foi en python te donne des oeillères. Et je dis ça en adorant Python.
Plus forte croissance: c'est normal. Python est plus utilisé que PHP. C++ aussi. Et C. Et Java. Ce sont des langages généralistes, PHP est un langage Web. La comparaison n'a pas de sens.
Même chose pour "développement d’applications d’entreprise, de bureau et scientifiques". PHP n'est pas fait pour ça. Un bon développeur choisit ses outils en fonction de la tâche.
Langage les plus utilisés pour développer du Web: l'étude qui montre HTML à la 10e place et Javascript à la 5e. C'est dire sa crédibilité. Si l'on inclut ces 2 langages, ils devraient être en 1e et 2e place loin devant tout le monde.

Pour conclure sur ce sujet, PHP est un excellent langage pour des sites et applications web de taille légère ou intermédiaire (çad l'immense majorité du Web, tous ceux qui ne sont pas de la taille d'Amazon, Twitter ou Reddit), permettant un développement rapide et facile et une bonne "maintainabilité" et facilité d'évolution grâce à son modèle objet. Dans les (très rares) cas où l'application grandit, et sous réserve qu'il ne soit pas monolithique (mais c'est une problème de développeur plus que de langage), on peut toujours changer les parties critiques en d'autres langages plus performants comme Java (ou Go ou Scala).

La plus grande faiblesse de PHP comparé à Python (et Ruby), ce ne sont pas ses bizarreries, ou son soi-disant problème de performance (corrigé par PHP 7) ou autres. C'est simplement que le niveau du développeur PHP moyen est plus faible que le développeur Python/Ruby moyen. Quand je vois le niveau de ceux qui sont soi-disant en "école" et qui viennent ici et ailleurs avec leurs problèmes, je me gratte la tête et j'espère qu'ils n'ont pas payé trop cher en frais de scolarité. Et quand ces "développeurs" arrivent en entreprise, ça rejaillit sur l'image des dev PHP en général comme des bricoleurs spécialistes du copier-coller et qui résolvent les problèmes par la force brute, pas par la réflexion. Ça dévalorise aussi le dév PHP, car sa valeur financière est dégradée en conséquence.

[SurferIX]

Pour conclure sur ce sujet, PHP est un excellent langage pour des sites et applications web de taille légère ou intermédiaire (çad l'immense majorité du Web, tous ceux qui ne sont pas de la taille d'Amazon, Twitter ou Reddit), permettant un développement rapide et facile et une bonne "maintainabilité" et facilité d'évolution grâce à son modèle objet. Dans les (très rares) cas où l'application grandit, et sous réserve qu'il ne soit pas monolithique (mais c'est une problème de développeur plus que de langage), on peut toujours changer les parties critiques en d'autres langages plus performants comme Java (ou Go ou Scala).

La plus grande faiblesse de PHP comparé à Python (et Ruby), ce ne sont pas ses bizarreries, ou son soi-disant problème de performance (corrigé par PHP 7) ou autres. C'est simplement que le niveau du développeur PHP moyen est plus faible que le développeur Python/Ruby moyen. Quand je vois le niveau de ceux qui sont soi-disant en "école" et qui viennent ici et ailleurs avec leurs problèmes, je me gratte la tête et j'espère qu'ils n'ont pas payé trop cher en frais de scolarité. Et quand ces "développeurs" arrivent en entreprise, ça rejaillit sur l'image des dev PHP en général comme des bricoleurs spécialistes du copier-coller et qui résolvent les problèmes par la force brute, pas par la réflexion. Ça dévalorise aussi le dév PHP, car sa valeur financière est dégradée en conséquence.

Tu as entièrement raison, et sur tous les points. La petite différence sur laquelle j'insistais c'est qu'aujourd'hui il est possible de faire la même chose en Python qu'en Php, ce qui n'était pas le cas hier, et donc que ses efforts d'évolution ne corrigent pas ses problèmes que je considère critiques c'est pourquoi je conseille un langage mieux sous tous les aspects (à mon sens).

[Aizen64]

PHP 7 a beau améliorer les nerfs, je pense que je n'apprécierai jamais ce language que je considère comme une m...

Les arguments :
- le debug : 20 ans après la création du language, personne n'a été en mesure d'implémenter un vrai debugger qui permet de faire de l'inspection de variable pas à pas. Je n'ai pas été en mesure d'installer xDebug, en comparaison Java et C# incluent ces fonctionnalités par défaut sans le moindre paramétrage.
- Typage faible : PHP 7 fait le travail à moitié. Au lien d'autoriser le typage de variable partout, seules les fonctions y ont le droit
- POO à revor, pas de surcharge de fonction. Il est vrai que ce type de fonctionnalité a moins d'intérêt vu le typage faible
- Des fonctions avec des noms à rallonge, exemples : simplexml_load_file() openssl_random_pseudo_bytes()

Là encore, personne pour retaper l'ensemble des lib en objets, obtenir la date et l'heure du jour, la classe DateTime est un bordel. Pas de date.now() sur un objet DateTime, ce serait trop compliqué.

A titre de comparaison, les 2 frameworks que sont Java et .NET n'ont pas 50 frameworks annexes qui gravitent autour du language (et pour cause ce sont des frameworks), PHP est un foutoir avec certains bons outils minimalistes et d'énormes usines à gaz.

Un dev bien plus expérimenté que moi m'a dit récemment, même moi, j'ai pas deux mois à perdre à apprendre cette usine à gaz qu'est Symfony. Cette remarque vient d'un dev qui a fait du C++ pendant son école d'ingé. C'est pas donné à n'importe qui de savoir utiliser ce langage.

[rawsrc]

Salut,

- le debug : 20 ans après la création du language, personne n'a été en mesure d'implémenter un vrai debugger qui permet de faire de l'inspection de variable pas à pas. Je n'ai pas été en mesure d'installer xDebug, en comparaison Java et C# incluent ces fonctionnalités par défaut sans le moindre paramétrage.

Ce n'est pas parce que tu n'y es pas arrivé que c'est merdique...
Si tu veux du débogage sans mettre les mains dans le cambouis, regarde du côté de NuSphere PhpEd : tu as nativement absolument tout ce que tu peux attendre d'un débogueur des autres langages.

Là encore, personne pour retaper l'ensemble des lib en objets, obtenir la date et l'heure du jour, la classe DateTime est un bordel. Pas de date.now() sur un objet DateTime, ce serait trop compliqué.

Euh... c'est compliqué de faire DateTime('now'); ou même par défaut tout datetime sans paramètre est équivalent à DateTime('now');. Au pire tu peux utiliser les constantes de formatage DATE_

A titre de comparaison, les 2 frameworks que sont Java et .NET n'ont pas 50 frameworks annexes qui gravitent autour du language (et pour cause ce sont des frameworks), PHP est un foutoir avec certains bons outils minimalistes et d'énormes usines à gaz.

Un dev bien plus expérimenté que moi m'a dit récemment, même moi, j'ai pas deux mois à perdre à apprendre cette usine à gaz qu'est Symfony. Cette remarque vient d'un dev qui a fait du C++ pendant son école d'ingé. C'est pas donné à n'importe qui de savoir utiliser ce langage.

Ben PHP est à l'image du libre : une tonne de produits et des développements plus ou moins au point ou aboutis.
C'est une force comme une faiblesse à la fois...

Pour ce qui est de Symfony, je te rejoins. Et crois-moi en entreprise, il y en a un paquet qui font marche arrière et cherchent à se rabattre sur du plus léger ou utilisent juste deux trois briques de ce framework et bazardent tout le reste.

Après il n'y pas de techno parfaite, il faut des développeurs derrière le clavier avec un cerveau et pas que des copistes.

[ABCIWEB]

Un dev bien plus expérimenté que moi m'a dit récemment, même moi, j'ai pas deux mois à perdre à apprendre cette usine à gaz qu'est Symfony.

Oui en même temps tu peux pas critiquer un langage parce qu'un framework créé avec ne te convient pas. Surtout quand il en existe une multitude d'autres. Et en plus tu n'est pas obligé d'en utiliser un.

C'est bizarre ces développeurs qui tiennent absolument à des contraintes (genre typage fort partout) et un minimum de choix dans les outils de développement.

Laissez-nous la liberté de choisir SVP PHP est "libre" et c'est bien qu'il le reste jusqu'au bout des ongles

[Aizen64]

Oui en même temps tu peux pas critiquer un langage parce qu'un framework créé avec ne te convient pas. Surtout quand il en existe une multitude d'autres. Et en plus tu n'est pas obligé d'en utiliser un.

C'est bizarre ces développeurs qui tiennent absolument à des contraintes (genre typage fort partout) et un minimum de choix dans les outils de développement.

Laissez-nous la liberté de choisir SVP PHP est "libre" et c'est bien qu'il le reste jusqu'au bout des ongles

Je suis entièrement d'accord pour le framework, pas obligatoire. Je critique le language parce que je le trouve bordélique, pas pensé pour être objet à l'origine avec des règles bien étranges sur certains points, des exemples :
- un booléen true sera rendu comme une chaine vide, pour le débug c'est une horreur,
- pas de try catch pour le SQL, c'est des options très pratiques en .NET avec des SQLException et super simples à mettre en place, à défaut en PHP, t'es obligé de gérer l'erreur sur ta variable de connexion qui retournera false en cas d'échec et de faire ta query ensuite. Pas de normalisation pour l'accès aux données (encore que, je peux me tromper avec PDO) donc tu te tappes des fonctions type mysql_query, pg_query et j'en passe qui sont toutes dépendantes du SGBD.
- retourner une constante dans une classe, $this->MaConstante ne marche pas, c'est du self:maConstance (????!)

Pour l'open source en général :
- très rares sont les projets qui ressemblent à un produit fini, les seuls produits auquel je pense qui sont finalisés sont VLC et Firefox. Linux ?

Le typage fort permet de forcer d'avoir une structure surtout.

[Nightfall]

un booléen true sera rendu comme une chaine vide, pour le débug c'est une horreur

c'est faux et si c'est booléen, tu dois t'en servir comme d'un booléen, pas comme une chaîne

Code :

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

1
2
3
$t = true;
echo $t; //affiche 1
echo (string)$t; //affiche 1

Pas de normalisation pour l'accès aux données (encore que, je peux me tromper avec PDO) donc tu te tappes des fonctions type mysql_query, pg_query et j'en passe qui sont toutes dépendantes du SGBD.

en effet, tu te trompes.

retourner une constante dans une classe, $this->MaConstante ne marche pas, c'est du self:maConstance (????!)

c'est logique, en tant que constante elle a la même valeur pour toutes les instances, donc self::maConstance a plus de sens que $this->MaConstante.

Pour l'open source en général :très rares sont les projets qui ressemblent à un produit fini, les seuls produits auquel je pense qui sont finalisés sont VLC et Firefox. Linux ?

lol, trop gros, passera pas, là la liste est trop longue.

[Spartacusply]

- un booléen true sera rendu comme une chaine vide, pour le débug c'est une horreur,

Non echo true; affichera en effet 1. Et pour le debug tu as var_dump, c'est carrément un argument non valable.

Pas de normalisation pour l'accès aux données (encore que, je peux me tromper avec PDO)

En effet tu te plantes vu que PDO est là pour ça justement. Il est bien sûr possible d'utiliser les exceptions avec PDO.

- retourner une constante dans une classe, $this->MaConstante ne marche pas, c'est du self:maConstance (????!)

Il est pour moi bien plus logique de faire self que $this qui référence à l'objet, la constante n'est pas rattachée à l'objet mais à la classe.

[Tsilefy]

Il me semble que sont juste les récriminations de quelqu'un qui s'est arrêté au PHP de 2007 et croit que rien n'a changé jusque là. Il ne faut pas se fier aux numéros de versions, PHP 5.3, 5.5 et 7 sont bien des versions majeures.

Et l'écosystème a largement changé depuis (outils, déploiement, le déclin du framework monolithique, qui décline en même temps que Rails décline, ce qui n'est pas un hasard, la montée des modules/librairies et de l'interopérabilité, etc...).

Je veux bien des critiques, mais qu'elles soient des critiques de la version utilisée actuellement (i.e. 5.6 et 7).