Discussion :

[ffert2907]

Certaines personnes penses que si ça ne coûte pas TRES TRES cher, ça vaut rien... il n'empêche que c'est la base de données la plus utilisée pour le web. Qui gère les clusters... la réplication, le merge entre base de données... Et dont les temps de réponses n'ont rien à envier à Oracle !... Sur certaines requête MySQL est plus rapide (requêtes sur plusieurs centaines de milliers d'enreg), il gère les recherches en FullText, et si l'on veut encore plus de rapidité on peut créer une base de donnée en MEMOIRE qui dans ce cas, est hyper rapides... Donc oui MySQL à ses limites, ce qui ne l'empêche pas d'être un trés bon produit, lorsque l'on commence à s'y intéresser... et... Rapport Qualité/Prix, entre un Mysql et un Oracle ou un MSSQL Server, désolé, je vote pour MySQL.

[Spartacusply]

Ben moi je pense pas que tant que ça ne coûte pas TRES TRES cher, ça vaut rien, mais je pense quand même que Mysql est une grosse daube

il n'empêche que c'est la base de données la plus utilisée pour le web

Et dont les temps de réponses n'ont rien à envier à Oracle !

Bouarf... (tu remarqueras que je ne cite aucune source mais toi non plus donc ça va).

il gère les recherches en FullText

Uniquement sous MyISAM, donc entre requête full text et contraintes référentielles choisir tu dois.

si l'on veut encore plus de rapidité on peut créer une base de donnée en MEMOIRE qui dans ce cas, est hyper rapides

Ben c'est pas exactement comme ça que ça marche, de toutes façons les autres SGBD le font aussi donc balle au centre.

Rapport Qualité/Prix, entre un Mysql et un Oracle ou un MSSQL Server, désolé, je vote pour MySQL.

Postgres, bord** !! Postgres !

PS : désolé j'ai un peu craqué là

[Chuck_Norris]

[Fulltext] Uniquement sous MyISAM, donc entre requête full text et contraintes référentielles choisir tu dois.

Plus maintenant, MySQL 5.6 gère le Fulltext sur InnoDB. De toute façon l'orientation d'Oracle est de pousser au maximum InnoDB pour proposer les fonctionnalités de ce moteur avec les avantages et les performances de l'autre maintenant clairement marqué obsolète ; d'ailleurs son fork MariaDB a suivi une approche différente en favorisant au contraire MyISAM et son moteur maison dérivé.

En ce qui concerne l'Unicode, certes le support de PHP n'est pas totalement natif mais il est tout à fait possible de développer des applications UTF-8 sans avoir besoin d'aucune bibliothèque externe.

[Shuty]

Il est clair que Php présente des lacunes quand on doit gérer les encodages de caractère mais d'une fois que l'on isole le "problème", des solutions existes. Il faut simplement faire du cas par cas même si cela est rébarbatif, je le conçoit

[saigone]

PHP 7 : la préversion PHP 7.0.0 RC 4 disponible,
cette nouvelle mouture vient corriger 22 bogues

L’équipe responsable du développement de PHP a annoncé la disponibilité de PHP 7.0.0 RC 4 qui vient deux semaines après la sortie de la préversion RC 3 (disponible depuis le 17 septembre 2015). Bien entendu, cette RC est déconseillé pour des utilisations en environnement de production. Cette préversion vient corriger 22 bugs et plus de 100 commits.

La préversion PHP 7.0.0 RC4 embarque une nouvelle version du moteur Zend qui dispose de la liste (non exhaustive) des fonctionnalités suivantes :

• rapidité accrue : PHP 7 est deux fois plus rapide que PHP 5.6 ;
• support des architectures 64 bits ;
• gestion de plusieurs erreurs fatales en exceptions ;
• combinaison des opérateurs de comparaisons (<=>) ;
• classes anonymes ;
• déclaration du type de retour ;
• déclaration du type scalaire.

Cette mouture corrige le bogue #70456 dans Mysqlnd découvert par Sergei Turchanov qui a remarqué que Mysqlnd n’activait pas de protocole de contrôle de transmissions quand il se connectait à un serveur. Elle corrige également le bogue #70013 dans Session découvert par Yasuo qui a réalisé que la référence à la variable de session $_SESSION était perdue après un appel de session_regenerate_id(). La liste complète des bogues corrigés et fonctionnalités de la préversion RC4 est disponible.

Les développeurs sont ainsi invités à tester cette nouvelle préversion de PHP 7 téléchargeable sur le site et encouragés à fournir les retours de bogues et incompatibilités rencontrés sur le site de bugs PHP.

La sortie de la préversion RC 5 est prévue pour le 15 octobre 2015.

Liste de bugs corrigés

Lien de téléchargement

Site de bugs de PHP

source : Site PHP

Et vous?

Comment trouvez-vous cette préversion PHP 7.0.0 RC 4?

Voir aussi
Forum PHP

Rubrique PHP(Cours, Tutoriels, FAQ, etc.)

[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...

[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

[Artemus24]

Salut SurferIX.

Je crois que tu n'as peut être pas assez fréquenté le monde du Web (grand bien t'en fasse, moi j'essaie tant bien que mal de m'en éloigner).

Je pensais que c'était évident : je n'ai jamais fréquenté le monde du web. Je viens du monde bancaire, gros système IBM et Unix.
Je fais du web depuis que je suis à la retraite !

Ça m’écœure de dire ça, mais la plupart des SSII fonctionnent ainsi.

Au moins sur la constatation que tu fais, nous sommes d'accord.

si, justement, l'argent est tout.

Je suis de la vieille école. L'argent, ce n'est pas mon problème, mais plutôt celui de mon commerciale et par voie de conséquence de mon patron dans la SSII.
Mon problème est de satisfaire le client. S'il veut de la merde, et bien il sera satsfait.
S'il veut du sur-mesure, il sera aussi satisfait. Je me suis toujours adapté aux besoins du client car c'est lui qui décide.
Mais quand le commerciale s'en mèle, c'est là que les problèmes commencent.
C'est pourquoi, j'ai toujours préféré faire de la régie plutôt que du forfait et de travailler directement avec le client.

Bienvenu dans le monde réel franco-français.

Penses-tu que c'est un problème typiquement français ?
J'ai fait des missions à Monaco et en Suisse, et bien, c'est pas mieux.

Toi, non : on dirait que tu y crois encore. Bravo !

C'est pourquoi, je suis devenu un raleur, jamais satisfait, exigeant que le travail soit bien fait, enfin l'emmerdeur qui empêche les autres de faire n'importe quoi.
Mais comme par hasard, quand un problème arrive, ce n'est jamais dans mon équipe, car voilà, j'ai pensé à l'impensable.
J'essaye d'anticiper les problèmes et quand je les dénonce, on me dot toujours que cela ne me concerne pas. Ah oui, mais cela concerne qui, puisque personne ne s'en soucie ?

Oui, je crois au travail bien fait, et non au cult de l'argent. L'argent n'est que la conséquence du travail bien fait. Sans travail, il n'y a pas d'argent.
Ce n'est pas au financier de diriger le monde mais bien à ceux qui produisent. Pour l'optimisation, oui, je veux bien que les financiers interviennent, mais après.
Encore une fois, ce que l'on a toujours tendance à faire en France, c'est de mettre la charrue avant les boeufs.
Et l'on est toujours surpris après coup, que rien ne fonctionne normalement.

Et tu continue à tenir le discours de "il faut bien faire son travail" ?

Si ce n'est pas moi que le fait, qui est-ce qui va se charger de le faire ?
Le commerciale ? Non, il n'a pas le temps, il compte ses sous.
Le patron ? Encore moins. Il se bat contre des lois stupides.

C'est à croire que je n'ai pas encore pris ma dose de déception pour virer de bord.

Dans ce cas fais comme moi : depuis que je suis indépendant, j'ai tout

J'ai été indépendant un certain temps. C'était pire que d'être prestataire de service dans une SSII.
Il faut dire que je n'ai jamais réussi à rencontrer les bonnes personnes avec qui j'avais envie de travailler.

Pas de patron pour hurler dessus et te demander de mentir comme tu l'as vécu, pas de stress car j'ai le temps de tout faire dans les délais, et je fais du travail avec toute la qualité qui va avec, et lorsque je ne suis pas content, je casse tout, et je ré-écris tout.

Là oui, je me retrouve dans la description que tu fais. Sauf que maintenant, je suis à la retraite, et je ne suis plus du tout stressé.
J'ai mis plus de deux ans à me calmer avant de trouver une certaine sérénité. J'étais hypernerveux et je ne me rendais pas compte durant mon activité professionnelle, et je n'ai jamais craqué !

Pour moi la qualité de vie passe avant toute cette mentalité franco-française qui me dégoûte et le monde du Web l'a exacerbée.

Je ne veux pas rentrer dans des considérations politico-économique, mais en France, c'est le bordel ambiant !
La compétence n'est plus au rendez-vous et on fait du grand n'importe quoi, juste pour justifier que l'on fait quelque chose.
Et cela ne va pas s'arranger dans les années qui viennent. C'est ce changement de mentalité que je ne comprends pas et qui va nous amener à la catastrophe.

Je te demanderai juste de bien considérer que même si je fais du Web, je ne fais pas partie des 99% de développeurs que tu décris - description pour laquelle je suis entièrement d'accord.

Je fais tenir compte de ta remarque ! Le problème des forums, c'est que l'on ne se connait pas et l'on a des a priori.
Je te signale au passage qu'être informaticien n'est toujours pas un métier reconnu comme celui des comptables ou des pharmaciens.
Et certains politiciens pensent, à tort, que n'importe qui peut devenir informaticien. Autrement dit, c'est la variable d'ajustment pour combattre le chomage.
Tant que ce métier ne sera pas bien encadré comme il se doit, on continuera d'exploiter les gens au nom de l'argent. Et avec toutes les dérives qui sont associées.

Je veux juste faire une remarque. Je n'ai rien contre toi et tu ne m'as pas offensé. J'ai juste réagit à tes propos pour te faire comprendre, que même si je suis informaticien, je n'ai pas le même parcours que toi, mais inversement, j'ai rencontré les mêmes problèmes et fait, encore aujourd'hui, les mêmes constatations.
J'ai connu une époque dans les années 70-80 où on avait du plaisir à pisser du code, comme tu dis. Et cette époque était enrichissante à tous les points de vue.
Aujourd'hui, je ne voie que des contraintes dans l'exercice du métier et aucun plaisir dans ce que l'on fait. Franchement, si j'avais 20 ans, je crois que je ne ferais pas d'informatique.

Et pour revenir au sujet, toutes les additions faites à Php 7 permettrons d'écrire le même code de manière différente, et pour moi ça n'est pas un avantage, c'est un inconvénient. Le seul intérêt que je vois à Php 7 est son gain de rapidité.

Je ne critique aucun langage, car chaque langage à ses raisons d'exister. Maintenant, la question demeure dans celle des développeurs. Un langage, pour faire quoi ?
Je sais que la question semble idiote au premier abord, mais tant que cela. Si le langage php est destiné à faire du web, il faudrait encore savoir ce que l'on entend par web.
J'ai abordé la question du langage php comme étant la gestion des balises html en fonction de certains critères coté serveur.
Aujourd'hui, ce langage est une boîte à outils, avec un peu trop d'environnements cloisonnés. On est dans du copier/coller qui a sa raison d'être.
Il réponds à un besoin qui, je suppose, a dérivé de sa fonction première. Comparativement, je préfère développer en php plutôt que faire du perl, ou du python.
Avant d'apprendre le php, je connaissais déjà le perl, et je trouve ce langage un peu trop lourd en terme de développement.
Quand on connait un langage et que l'on est à l'aise avec, pourquoi changer ?
Je me verais mal, faire du cobol ou du 'C/C++', voire du java pour gérer un site web.
Maintenant, si je dois faire de gros calculs, le 'C/C++' est bien adapté à ce genre de problème.

Je pense que l'on doit créer des outils pour répondre à des besoins particuliers.
Chaque outil aura sa philosophie. Mais le problème reste la gestion de ces outils au sein d'un langage supérieure qui viendra les encapsuler. Est-ce le rôle du php ?
Je pense que le php n'a jamais été concu pour faire cela. Ce qui le rend justement bordélique aux yeux de certains.
Au lieu de se fixer sur le typage fort ou faible, qui est un faux problème, il faudrait mieux dénoncer en quoi le php ne répond pas aux besoins des développeurs.

P.S.: c'est moi qui met des +1 partout !

@+

[macslan]

Penses-tu que c'est un problème typiquement français ?
J'ai fait des missions à Monaco et en Suisse, et bien, c'est pas mieux.

En quoi c'est pas mieux ?

Je te signale au passage qu'être informaticien n'est toujours pas un métier reconnu comme celui des comptables ou des pharmaciens.
Et certains politiciens pensent, à tort, que n'importe qui peut devenir informaticien. Autrement dit, c'est la variable d'ajustment pour combattre le chomage.
Tant que ce métier ne sera pas bien encadré comme il se doit, on continuera d'exploiter les gens au nom de l'argent. Et avec toutes les dérives qui sont associées.

Il faut dire qu'informaticien c'est un grand terme mais en Suisse en tout cas vaut mieux faire un CFC pour trouver un job en tant qu'informaticien

[RyzenOC]

PHP7 devrait sortir le 26 novembre:

https://wiki.php.net/todo/php70#timetable

[lingtalfi]

Excellent!

[Zefling]

J'ai bien essayé de l'installer pour tester mes sites, mais ça ne fonctionne pas.

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
root@debian-Z1:/opt/php-7.0.0/lib/php/build# systemctl restart apache2                                                    
Job for apache2.service failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details.
root@debian-Z1:/opt/php-7.0.0/lib/php/build# systemctl status apache2.service
● apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2)
   Active: failed (Result: exit-code) since sam. 2015-10-03 00:56:50 CEST; 5s ago
  Process: 19180 ExecStop=/etc/init.d/apache2 stop (code=exited, status=0/SUCCESS)
  Process: 19208 ExecStart=/etc/init.d/apache2 start (code=exited, status=1/FAILURE)
 
oct. 03 00:56:50 debian-Z1 apache2[19208]: Starting web server: apache2 failed!
oct. 03 00:56:50 debian-Z1 apache2[19208]: The apache2 configtest failed. ... (warning).
oct. 03 00:56:50 debian-Z1 apache2[19208]: Output of config test was:
oct. 03 00:56:50 debian-Z1 apache2[19208]: apache2: Syntax error on line 224 of /etc/apache2/apache2.conf: Cannot load /usr/lib/apache2/modules/libphp7.so into server: libreco...or directory
oct. 03 00:56:50 debian-Z1 apache2[19208]: Action 'configtest' failed.
oct. 03 00:56:50 debian-Z1 apache2[19208]: The Apache error log may have more information.
oct. 03 00:56:50 debian-Z1 systemd[1]: apache2.service: control process exited, code=exited status=1
oct. 03 00:56:50 debian-Z1 systemd[1]: Failed to start LSB: Apache2 web server.
oct. 03 00:56:50 debian-Z1 systemd[1]: Unit apache2.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

Il y en a qui ont ce genre de problème ? Bref, je suis retourné sur le 5.6.

[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.

[Olivier Famien]

La date de sortie de la version stable de PHP 7 pourrait être repoussée
pour améliorer la qualité du code, qu’en pensez-vous ?

Le 29 octobre dernier, PHP 7 RC 6 a été publié. Cette nouvelle version constitue la 11^e du genre parmi la série des préversions publiées jusqu’alors. Dans cette préversion, 10 nouveaux bogues ont été corrigés.

Au menu des erreurs corrigées, l’on notait, entres autres, qu’une exception déclenchée lors d’une comparaison identique engendrait une boucle infinie. Le gestionnaire d’exceptions ne fonctionnait pas comme prévu. Un débordement de la mémoire de la pile a été détecté dans le parser du langage Zend. Le client SOAP générait Segfault. Un défaut de segmentation a été observé dans le client SOAP. Une sérialisation incorrecte de l’objet ArrayObject pointait du nez si la fonction unset était appelée dans la fonction serialize().

Tous ces éléments et bien d’autres encore ayant été corrigés dans cette 6e Release Candidate de PHP7, la prochaine étape selon le planning devrait être la sortie de la version finale le 12 novembre.

Toutefois, Anatol Belski, développeur du noyau de PHP et gestionnaire de la publication de PHP 7.0, a annoncé depuis peu « qu’après les dernières évaluations dans le cercle des gestions de versions précédant l’orientation vers les préparations pour la version 7.0 RTM, nous sommes parvenus à la conclusion que l’état actuel ne parait pas raisonnable pour être utilisé comme la version finale ».

« Les versions Release Candidate avant la version RC6 apparaissaient acceptables, ce qui nous a donné des motifs pour annoncer la date de la version RTM programmée pour le 12 novembre comme finale. À partir de la perspective d’aujourd’hui, la plupart des problèmes découverts et corrigés depuis la version RC6 sont encore mineurs en raison de leurs caractéristiques – 7 crashes (le bogue #70805 plutôt critique) et 3 régressions de fonctionnalité. Toutefois, étant donné la quantité et la combinaison de tous ceux-ci, l’état est à notre avis impropre pour le démarrage du cycle de vie de la prochaine version majeure ».

« Ainsi, la reprise du cycle des préversions semble de notre point de vue la chose appropriée à faire pour l’instant. D’où cette adresse pour informer la communauté sur l’intention et recueillir les avis. PHP 7 est toujours dans la dernière ligne droite et est très proche de l’achèvement. La prochaine version RC sera peut-être bien la dernière. Bien que nous préférions nous assurer d’abord de la qualité autant de fois que possible au lieu de fournir un mauvais service aux consommateurs ».

À la lumière de cette annonce, il ne serait pas incongru de conclure que la date du 12 novembre pour la sortie de la version RTM de PHP 7 sera repoussée afin que le produit une fois sorti ne souffre aucunement de défaut de qualité.

Certaines personnes trouvent cela raisonnable de repousser cette date si la qualité actuelle n’est pas optimale pour l’instant. Et d’ajouter que ce serait nul de publier une chose qui une fois sortie serait remplie de bogues.

D’autres par contre ne trouvent aucune objection à ce que la date initiale soit respectée en dépit de la qualité du produit qui pourrait être reprochable. Des corrections d’erreurs pourraient suivre à mesure que les découvertes de bogues seront faites, soutiennent ces derniers.

Source : PHP News

Et vous ?

Que pensez-vous de cette annonce ?

Que pensez-vous de ce report probable ?

Voir aussi

Forum langage PHP

[ABCIWEB]

Salut,

Je suis de l'avis du premier groupe qui préfère retarder la sortie. Pourquoi sortir une version alors que des bugs récents ont été découverts ? Même corrigés mieux vaut prendre le temps de vérifier qu'ils n'ont pas d'autres impacts, et que les corrections proposées soient testées dans toutes les combinaisons possibles.

En plus les dernières versions de php depuis 5.3 ont notablement amélioré les performances, ce qui à mon avis permet d'attendre encore quelques semaines dans de bonnes conditions sans trop d'impatience.

Et puis php commence à perdre son aspect amateur, qui en fait n'était pas dû au langage lui-même mais à la grande diversité de niveau des utilisateurs puisqu'étant le langage le plus accessible c'est aussi celui qui attire le plus de débutants.

L'équipe php a augmenté les contrôles minimum pour récupérer des variables, fourni un bon cadre pour le développement objet, des nouvelles classes bien pratiques, des gains en performances pour les dernières versions etc. sans oublier les nombreux framework construits autour qui se sont eux aussi améliorés. De quoi satisfaire le plus grand nombre.

Pourquoi prendre le risque de contrarier cette montée globale qualitative en sortant une version buggée qui cette fois-ci ramènerait le problème non plus à la maladresse de certains débutants mais au moteur du langage lui-même. Ce serait une bien mauvaise publicité
Tout ça pour respecter une date ? Nan franchement, sauf à donner le bâton pour se faire battre, quel intérêt ?

[macslan]

Salut,

Je suis de l'avis du premier groupe qui préfère retarder la sortie. Pourquoi sortir une version alors que des bugs récents ont été découverts ? Même corrigés mieux vaut prendre le temps de vérifier qu'ils n'ont pas d'autres impacts, et que les corrections proposées soient testées dans toutes les combinaisons possibles.

En plus les dernières versions de php depuis 5.3 ont notablement amélioré les performances, ce qui à mon avis permet d'attendre encore quelques semaines dans de bonnes conditions sans trop d'impatience.

Et puis php commence à perdre son aspect amateur, qui en fait n'était pas dû au langage lui-même mais à la grande diversité de niveau des utilisateurs puisqu'étant le langage le plus accessible c'est aussi celui qui attire le plus de débutants.

L'équipe php a augmenté les contrôles minimum pour récupérer des variables, fourni un bon cadre pour le développement objet, des nouvelles classes bien pratiques, des gains en performances pour les dernières versions etc. sans oublier les nombreux framework construits autour qui se sont eux aussi améliorés. De quoi satisfaire le plus grand nombre.

Pourquoi prendre le risque de contrarier cette montée globale qualitative en sortant une version buggée qui cette fois-ci ramènerait le problème non plus à la maladresse de certains débutants mais au moteur du langage lui-même. Ce serait une bien mauvaise publicité
Tout ça pour respecter une date ? Nan franchement, sauf à donner le bâton pour se faire battre, quel intérêt ?

D'ailleurs ça me rappelle les jeux vidéo et ceux qui râlent que le jeu sortent plus vite puis râlent à cause des bugs

[RyzenOC]

J'ai tester la dernière RC est je n'ai pas découvert bugs.

Mais je préfere avoir un produit en retard mais de qualité, je suis plutôt pour un report.