Discussion :

[Julien Breux]

Quel est serrai le niveau d'erreur en cas de mauvais typage ?

[Yogui]

Cela n'a pas été évoqué pour le moment.

Voici ce qui figure dans le Wiki, liste des choses à faire pour PHP6 :

Todo items
- optional typehinted parameters DONE (derick)
- add support for type-hinted return values.
Dropped items
- Implement inheritance rules for type hints. (marcus)
- add Typehinted properties (marcus)

[zevince]

Personnellement, j'utilise les typages existants, c'est meme parfois obligé.. Mais la force de php est sa simplicité d'apprentissage.. Et je n'aurais pas aimé devoir typer toutes mes variables quand j'ai commencé..

Il me semble aussi qu'il existe beaucoup de langages ou le typage est obligatoire ..

Donc que chacun choisisse ses outils.. mais pourquoi vouloir faire de php une sorte de copie de java.. ?
j'adore les fonctionnalités objet de php.. mais je n'aimerais pas que ca soit imposé comme en java.. et pour le typage, il me semble aussi que laisser au developpeur le choix.. est une bonne option.. Apres, a chacun de controler son code..

[Julien Breux]

Personnellement, j'utilise les typages existants, c'est meme parfois obligé.. Mais la force de php est sa simplicité d'apprentissage.. Et je n'aurais pas aimé devoir typer toutes mes variables quand j'ai commencé..

Il me semble aussi qu'il existe beaucoup de langages ou le typage est obligatoire ..

Donc que chacun choisisse ses outils.. mais pourquoi vouloir faire de php une sorte de copie de java.. ?
j'adore les fonctionnalités objet de php.. mais je n'aimerais pas que ca soit imposé comme en java.. et pour le typage, il me semble aussi que laisser au developpeur le choix.. est une bonne option.. Apres, a chacun de controler son code..

Je suis d'accord, pas de PHP version Java II !

[Laplix]

Personnellement, j'aimerais bien un typage "moyen".

Par exemple, si je code

Code php :

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

function maFonction($aString, $aInt) {...}

je m'attends à des conversions de la part de PHP. Donc un type mixed par défaut.

À noter que j'utilise rarement cet effet. Si une fonction attend un chaine en paramètre, je lui envoie une chaine.

Par contre, dans certains cas, j'aimerais bien être plus strict.

Code php :

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

1
2
array function maFonction(string $aString, int $aInt) {...]
$myString = maFonction(1,'1');

L'appel devrait générer une exception de la part de PHP.

Si j'exige des paramètres et un retour typés à l'écriture de la fonction, j'ai surement une bonne raison et j'aimerais bien me faire rappeler à l'ordre par PHP si je ne fournis pas ou ne retourne pas les bonnes valeurs.

Cela permettrait alors la surcharge des fonctions, même de celles qui ne sont pas typées puisque leur signature seraient par défaut

Code php :

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

mixed function maFonction(mixed $aString, mixed $aInt) {...]

Surement mieux que d'utiliser __call() pour simuler les surcharges?

[lespoches]

Selon toi, si j'appelle ce code, que se passe-t-il ?

Code :

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

1
2
3
<?php
function ma_fonction (string $texte, int $nombre, float $prix) { }
ma_fonction (1, '2', 1.0);

Il me semblerait logique ou souhaitable que PHP convertisse 1 en chaîne (puisque compatible) et 2 en entier (puisque compatible), mais ne lance pas d'erreur.

Ayant fait quelques allez retour entre Java et php, je suis à 100% pour un typage fort.
Je m'expliques !
Un Bon développeur, à mon sens, doit s'assurer des info(Contenu, typage) qu'il transmet au méthodes ou fonctions qu'il utilise ! C'est un gage de qualité, de maintenabilité ... !
Forcément quand tu es dans une boite qui cherche tout le temps la rentabilité max, on peux tous coder avec les orteils, seulement à long terme, ce n'est pas intéressant !

Quand tu bosses sur un gros projet et que tu fais de l'horizontal , ca permet de t'assurer que les autres (rest of the world) n'utilisent pas tes méthodes n'importe comment.

Donc up pour le typage fort !

[Yogui]

@lespoches : Pourquoi ne pas considérer que c'est le langage qui s'occupe de faire automatiquement la conversion lorsqu'il en est capable (avec des règles bien documentées), et au développeur lorsque c'est ambigü ? Je trouverais dommage d'avoir un typage fort dans un langage à types dynamiques

[lespoches]

Excuse moi mais quand je vois des horreurs dans ce genre, ca m'horripile un peu !

if (!func())

est vrai si func() retourne false, 0, null ou ""

Pour moi false c'est false, c'est pas 0 ou null ou quoi que ce soit d'autre! Vieille pratique hérité d'un autre age au passage (les bon vieux code retour lol)!

[goodpz]

Du moment que ces strict type hints soient optionnels, alors je suis 100% pour!

[Invité2]

Je suis assez d'accord avec goodpz, ça serait bien qu'on ait plus à répéter des trucs comme ça :

Code :

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

$maVariable=(int)$maVariable;

Ca faciliterais pas mal la lecture

[FoxLeRenard]

Bonjour toutes et tous

Moi aussi je suis partagé, c' est la grande libertée, que PHP offre mais un risque en un tout petit mouvement de perdre des données ...

$test="12abon";
$test=$test+1;
echo ("".$test."<br />");

Affichera 13 bien sur ...

[Yogui]

@FoxLeRenard : c'est documenté dans le manuel, un programmeur qui a lu le manuel sait donc ce qu'il se passe ici.

Lorsque tu utilises "+" sur une chaîne, tu la convertis en nombre. Ce n'est pas Java ou JavaScript où "+" est utilisé pour concaténer, car en PHP "+" n'est utilisé que pour les additions, pour concaténer c'est "."

Raisonnement inverse : Un programmeur qui utilise "+" pour concaténer fait une erreur de logique, ainsi il est tout à fait naturel que son code n'agisse pas comme il le croit.

Pour revenir à ton exemple, un programmeur qui sait ce qu'il fait ne voit pas là une "perte de données" mais bien un comportement normal. Ce n'est donc pas un problème mais plutôt un avantage

[FoxLeRenard]

a répondu ...

Tout a fait OK avec toi, mais je faisait cette remarqur pour souligner ce comportement que nous ne rencontrons que dans ce langage !

Nous sommes loins de la rigueur de l'assembleur des années 70

Merci de ta réponse.

[BobLunique]

Tout a fait OK avec toi, mais je faisait cette remarqur pour souligner ce comportement que nous ne rencontrons que dans ce langage !

Avec mysql :

SELECT 10+"20 PETIT ";

donne 30


SET GLOBAL SQL_MODE = 'ANSI';
SELECT 10+"20 PETIT ";

( erreur de syntaxe )

[FoxLeRenard]

Avec mysql :

SELECT 10+"20 PETIT ";

donne 30


SET GLOBAL SQL_MODE = 'ANSI';
SELECT 10+"20 PETIT ";

( erreur de syntaxe )

Oui belle démonstration

[Yogui]

souligner ce comportement que nous ne rencontrons que dans ce langage !

C'est incorrect, PHP n'est pas le seul langage à se comporter ainsi : Perl est un autre exemple.

[patouche]

Pour rajouter ma goutte,

Je préférerais presque un typage fort. que l'on déclare nos variable et tout et tout. Pas contre, hors de question d'avoir des choses impossibles comme des cast débiles de Integer à int...

Enfin, il est vrai qu'avoir une solution comme proposé sur la première page ou l'on a des prototype de fonctions serait un truc génial. Et puis pourquoi pas avoir le déclenchement d'un warning lorsque l'on fait des choses "bizarre"...


Cordialement,
Patouche

[aityahia]

Salut

pour un langage tel que php ou toutes les données qui transitent entre le serveur et le client sont au format texte, je pense que le typage fort n'est pas un avantage, mais bien au contraire va générer des entraves et d'infructueux efforts de développement supplémentaire.

par contre si parfois un typage fort strict peut s'avérer nécessaire je pense que le mieux c'est de données la possibilité au développeur d'activer de de de désactiver le typage fort.

salutations

[s.n.a.f.u]

C'est incorrect, PHP n'est pas le seul langage à se comporter ainsi : Perl est un autre exemple.

Exact, et php est franchement un dictateur quand tu compares à perl. Combien de fois ne me suis-je fourvoyé juste à cause de la notion de contexte ! Et pourtant, j'aime beaucoup perl.

Pour en revenir au sujet, les prototypages possibles depuis php5 sont sympas, et je pense que cela suffit.
Le typage fort ne servirait qu'à éclater les malades du design pattern.
Et quid de la compatibilité descendante alors que beaucoup de fonctions php peuvent renvoyer une valeur (string, integer), ou un objet, ou même encore le booléen false ?

[s.n.a.f.u]

La seconde qui fait plus appelle au génie logiciel (objet, réflexion, design pattern, conventions d'écriture souvent plus élaborée)

En quoi la POO nécessite-t-elle vraiment du typage fort ?
php5.3 et perl prouvent depuis longtemps qu'on peut faire de l'objet sans typage fort.
Et encore une fois, ça évite les design pattern usines à gaz du genre décorator.