Discussion :

[RideKick]

Salut

Depuis quelque temps sur la liste interne de discussion du PHP Group, Internals, un débat fait rage autour des "type hints".

Comme vous le savez, PHP est un langage à typage faible. Cela signifie que l'on peut écrire :

Code :

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

1
2
3
$var_1 = '1';
$var_2 = 1;
echo $var_1 == $var_2 ? 'égaux' : 'différents'; //affiche "égaux"

La comparaison se passe sans problème et le résultat est même positif. C'est ce que l'on appele le "type juggling", très utile dans de nombreuses situations puisque les données en provenance de bases de données et des navigateurs Web sont généralement au format texte.

Certaines personnes aimeraient pourtant retrouver une syntaxe proche du C avec un typage fort, voire strict. Cela se ferait à deux niveaux :

• Pour les paramètres des fonctions ;
• Pour les valeurs de retour des fonctions.

Il existe plusieurs approches.
Un typage "fort" obligerait tous les développeurs utilisant une API à convertir les valeurs avant d'appeler les fonctions de l'API :

Code :

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

echo htmlspecialchars((string)$var, ENT_QUOTES);

À la longue, cela risque d'être très fatigant...

Code :

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

1
2
3
4
5
6
function speak(int $number)
{
   var_dump($number);
}
 
speak('1'); //erreur de type

Une autre approche consiste à laisser un typage faible, mais à obliger une conversion automatique dans le type indiqué :

Code :

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

1
2
3
4
5
6
function speak(int $number)
{
   var_dump($number);
}
 
speak('1'); //affiche "1" après conversion en entier

À mon sens, cette dernière proposition est assez alléchante. Si autoriser un typage fort est prévu pour PHP, j'aimerais autant qu'il ne soit pas totalement "strict".

Par ailleurs, un typage strict ferait double emploi avec :

• Le parseur PHP (erreurs d'analyse du code source par le Zend Engine) ;
• Certaines fonctions historiques très utiles comme sprintf(), qui font un très bon usage du type juggling.

La même proposition vaut pour les types de retour des fonctions.

Qu'en dites-vous ?
cf. http://blog.developpez.com/index.php...&p=5546&more=1

[Phelim]

Il est vrai que dans un sens, la solution de la conversion obligatoire est interessante pour fiabiliser d'une application.

Voici les points forts que je vois pour la premiere methode :

• API plus solide
• Erreur ou exception ayant plus de chance d'apparaitre relative au typage durant le developement

Les points faible :

• Ennuyeux a la longue
• Erreur non habituel pour les concepteurs de PHP

Point fort de la deuxieme:

• Invisible pour le developeur

Point faible :

• Effet de bord possible a cause du changement de type
• Aucune evolution par rapport a l'usage actuel de PHP

Je ne suis pas forcément pour la premiere methode.
La deuxieme est plus problématique car elle rajoute une couche qui au final sert un peu à rien. On est au meme point que php aujourd'hui. La conversion se fait a l'entrée de la fonction au lieu du moment ou l'en en a besoin.

Je comprends tout a fait que pour un usage professionnel (en fait quand on dit ça, ça a plutot le sens pour assurer une application de production aussi proche que possible de ce que le developpeur developpe), un typage fort est plus interessant.

PHP avec un typage fort batard comme mentionné (premiere et deuxieme methode), je trouve que c'est un retour en arriere.
Soit on fait un véritable typage fort (comme en C) soit un typage faible (comme actuellement).

Mais je ne suis pas adepte du entre les 2.

[neissa]

Code :

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

1
2
3
4
 
$var_1 = '1';
$var_2 = 1;
echo $var_1 == $var_2 ? 'égaux' : 'différents'; //affiche "égaux"

Oki cependant

Code :

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

1
2
 
echo $var_1 === $var_2 ? 'égaux' : 'différents';  //affiche "différents"

Pour les adèpte du typage fort rajoutez un =

Le typage des variables ne fiabilise en rien une application ça donne juste une impression de sécurité au développeur qui en fait n'est que du vent.
De plus les sprintf sont une horreur pour les performance d'un API, le PHP ( 5 et inférieur ) n'as pas la chance d'être précompilé nativement donc les perfomances de celui-ci sont pas jolies jolies, vivement PHP6 mais non au typage fort !

La meilleur des solutions est de ne pas copier d'autre langage qui sont très utilisé mais loin d'être des exemples.

Que vive le typage faible !

[grunk]

Je suis assez d'accord avec neissa. Le typage faible de php est a mon sens un énorme avantage et surtout un gain de temps non négligeable.

Moi qui est l'occasion de faire quelques petits développement en C ou en Java , je trouve le typage très pénible.

Je suis bien d'accord qu'il est important sur un gros projet C/JAVA/embarqué d'optimiser la mémoire et donc de bien choisir ces types mais pour du web je vois pas l'intérêt.
On sera de toute manière limité par la performance globale du langage avant d'être ennuyer par des souçis lié au typage (à mon avis).

Et encore une fois comme le précise neissa , si le type vient à avoir son importance dans une appli , on à de quoi le vérifier.

Conclusion je plussois le typage faible également

[Invité]

Mon avis : je ne suis pas pour un typage fort, mais un typage strict des fonctions et/ou méthodes.

Ca aide énormément dans le cadre de développement de bibliothèques orientées objets et de framework.

Si je pouvais avoir une structure du type

Code :

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

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

je serai ravi.
Il est déja possible de typer sur des objets (ou des interfaces) et des tableaux, pourquoi ne pas étendre ces possibilité à tous les autres types PHP ?
Ca nous aiderait bien dans le cadre du développement de ZendFramework, par exemple ( ou de tout autre outils )

Il existe des extensions déja, notamment dans la SPL, pour typer des floats ou des int, avec

Code :

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

1
2
$int = new SPLInt(8);
$flt = new SPLFloat(4.9);

Voyez ici pour les curieux


Pour le typage fort, je suis contre. Un bon développeur connait par coeur les règles de convertion de types de PHP, et les utilise à bon escient : c'est tout simplement profiter d'une fléxibilité du langage, il ne faut pas l'enlever.

[Yogui]

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.

[SphynXz]

je pense que le problème ici est de demander à php d'être stricte et souple en même temps.

Pour ton exemple Yogui, je prefère nettement que PHP m'avertisse d'une erreur de passage d'argument.

quoique si ce que j'attend est un int, et que je récupère un int qui entre temps à été converti en string par je ne sais quel étape du code (récupération bdd...), là ca peut devenir intéréssant.


PS : parle-t-on du futur de php??? parce qu'il me semblait que le type hinting ne fonctionnait que pour les classes et les tableaux?

[Er3van]

Suite à la remarque de Yogui me vient un doute, est-ce que PHP implémente le surtypage des fonctions ??

Si oui, alors un typage strict des fonctions peut effectivement s'avérer pratique. Dans le cas contraire, comment gérer les types en entrée d'une fonction ?


Pour revenir à la discussion principale, je reste partagé. D'un côté, habitué à développer en java, C, C++, le typage fort et stricte est devenu habituel et logique. Ca permet à mes yeux d'avoir une meilleure cohérence d'ensemble.

Cependant, le langage faiblement typé qu'est PHP apporte pas mal d'avantage, dont une certaine souplesse et de temps appréciable. Pour les retours de fonction c'est d'ailleurs particulièrement utile de pouvoir retourner, selon le contexte, un tableau, un binaire ou un entier....

[kaymak]

Pour.

Le typage avec conversion automatique des types scalaires.
Avec la possibilité de choisir de ne pas déclarer les types en entrées/sorties.

Comme cela il ne sera plus nécessaire de re typer des arguments en entrées
genre : $t = (int)$t;

...... Argument de fainéant ? Juste un peu

Mais bon en même temps on utilise le typage en entrée / sortie partout, en PHP comme ailleurs.
Lors de la rédaction des docs, lors de l'utilisation d'une fonction/méthode, lors de l'écriture de la-dite fonction/méthode, alors pourquoi laisser cette information se volatiliser et se perdre dans un espace purement informatif de documentation....

[fred_avignon]

Bonjour.

Alors moi je suis pour un typage fort.

J'ai fait du Java, du c++, du PHP et ma conclusion est sans appel : plus le typage est fort moins il y a de risques de bugs.

J'ai l'habitude de faire de la programmation défensive et je fait vérifier le maximum de choses par le compilateur.
En PHP, le typage "lâche" est une plaie car certains transtypages se font de manière invisible et génèrent des bugs très difficiles à trouver.

Mes années d'expériences me prouvent que l'apparente facilité de l'absence de typage est un leurre. Le temps soit-disant gagné à l'écriture se perd lors du débuggage.

Dans tout langage, il faut absolument éviter tout ce qui se fait de façon implicite, sans que le développeur l'ai explicitement demandé.

[fred_avignon]

Pour le typage fort, je suis contre. Un bon développeur connait par coeur les règles de convertion de types de PHP, et les utilise à bon escient : c'est tout simplement profiter d'une fléxibilité du langage, il ne faut pas l'enlever.

Les bons développeurs ne représentent qu'un petite proportion des développeurs. Les autres utilisent plus ou moins bien les conversions de types sans connaître les exceptions et cas particuliers. C'est source de beaucoup d'erreurs.
Même moi après plusieurs années de PHP je suis parfois surpris du comportement de PHP et je peste contre l'absence de règles constantes. C'est pourquoi je m'impose de renoncer aux conversions de types automatique en refusant dans mes fonctions les types non souhaités.

Exemple :

function x($machaine)
{

if (!is_string($machaine))

throw new exception;

// ... traitement

}

Avouez que ça rajoute du travail en plus pour rien.

Et si je veux absolument passer un integer à ma fonction :

$i = 1;
x((int)$i);

Cette technique me garantie de savoir précisément ce que je passe.

[MikaMTB31]

Si je pouvais avoir une structure du type

Code :

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

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

je serai ravi.
Il est déja possible de typer sur des objets (ou des interfaces) et des tableaux, pourquoi ne pas étendre ces possibilité à tous les autres types PHP ?

J'achète. Cette simple modif satisfairait les gens qui s'inquiètent de monter des API sûres, et les autres qui veulent 'ne pas se prendre la tête' en écrivant leur code. Je pense qu'on aura du mal à faire mieux.

Pour répondre à Yogui, pour moi, l'interpréteur doit planter sur cet exemple si les types des donnees passees sont mauvais. C'est à ça que sert la spécification des types. Si on veut la souplesse, on ne met rien.

[Yogui]

Suite à la remarque de Yogui me vient un doute, est-ce que PHP implémente le surtypage des fonctions ??

En partie avec l'héritage, mais de base non PHP n'a pas de surcharge de fonctions à la manière de C ou Java. La raison est simple : la signature d'une fonction PHP est son nom, tandis que la signature d'une fonction C ou Java est son nom + son type de retour + le type de chacun de ses paramètres (ce que personnellement je trouve très confus).

[Phelim]

Confus, je trouve qu'au contraire c'est pas plus mal.

Ca permet de gérer le polymorphisme. Ainsi, on peut gérer la difference dans une meme fonction de maniere elegante si c'est un tableau, un int ou un string.

Apres ça ouvre aussi la porte à beaucoup d'abus (comme des qu'on laisse des libertés ) par exemple comme le typage faible de php

Même moi après plusieurs années de PHP je suis parfois surpris du comportement de PHP et je peste contre l'absence de règles constantes. C'est pourquoi je m'impose de renoncer aux conversions de types automatique en refusant dans mes fonctions les types non souhaités.

Exemple :

function x($machaine)
{
if (!is_string($machaine))
throw new exception;
// ... traitement

}

Ca c'est bien.
Quand on crée une API, ce genre de chose est facile a faire. Une api c'est souvent apporter des possibilités à ceux qui ne sont pas capables de les utiliser (genre generer un fichier pdf ac quelques lignes de code)
Si l'auteur juge qu'il doit controler ces données d'entrée, rien ne l'empeche de le faire.

Apres, on parle de sécurité, de developpement industrialisé. Seulement il y'a des personnes qui s'en foutent et ça peut se comprendre. La seule chose qu'il veule c'est créer un script php facilement sans se prendre la tete.

Bon faut etre honnete, sur php, il y'en a de moins en moins.
Sans rentrer dans un débat, les personnes que je cotoyais qui programmait en php et qui ont arreté, l'ont fait a cause de la POO.

Pourtant la POO c'est super. Mais ce n'est pas ce que ces personnes recherchaient pour faire du php.

Un typage fort, on en perdra peut etre moins en route mais pour PHP, c'est une marche de plus vers la professionnalisation du language (ce qui a son interet aussi)

Donc je redonne mon avis : neutre

[savageman86]

La Core Team de PHP n'a pas dans l'intention d'introduire un typage fort car c'est en (grande) partie grâce à ça que le langage est si simple à prendre en main.

Ceci dit, je suis totalement pour qu'un typage soit introduit dans les définitions des fonctions, à la manière des objets et array en PHP 5, et ce même pour les types de base (string, int, float, bool, etc...), qui à pouvoir spécifier mixed lorsqu'on s'en fout (où plutôt avoir mixed comme valeur "par défaut", comme actuellement).

+1 pour doctorrock donc

[BobLunique]

A toujours suivre les autres on reste toujours derriere ( PHP qui "cours" apres les langages typés me déplait ... )

Ceci dit, je suis totalement pour qu'un typage soit introduit dans les définitions des fonctions, à la manière des objets et array en PHP 5, et ce même pour les types de base (string, int, float, bool, etc...), qui à pouvoir spécifier mixed lorsqu'on s'en fout (où plutôt avoir mixed comme valeur "par défaut", comme actuellement).

+1 pour doctorrock donc

[Yogui]

Pour rappel, PHP travaille constamment avec des données au format texte (XML, SGBD, formulaires...), ce qui est la raison principale pour le succès du type juggling (typage dynamique). C'est ce qui fait, à mes yeux comme aux yeux de certains développeurs du PHP Group, l'absurdité des type hints tricts en PHP.

Je comprends qu'un langage de programmation bas niveau (C, C++) aie l'utilité d'un tel contrôle puisqu'ils permettent au programmeur de manipuler très précisément la mémoire utilisée par son programme. Cependant, PHP est une forme de langage managé, ce n'est pas le code PHP lui-même mais le Zend Engine qui alloue et libère la mémoire système nécessaire à ses variables. Par conséquent, un typage fort en PHP n'a aucun sens. Sans compter qu'une variable peut de toute manière changer de type au cours de l'exécution de la fonction, ce qui confirme mon sentiment d'absurdité par rapport au typage strict.

Pour moi, c'est clair : le typage strict n'est pas prévu pour PHP. Par contre, je ne change pas d'avis, le code suivant me semble parfaitement acceptable si le typage est vu comme "conversion forcée" plutôt que "typage forcé" :

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);

[meliandah]

Personnellement je reste toujours rigoureux avec mes variables lorsque je programme en PHP et j'essai de toujours garder le même type pour une variable sans que cela soit préciser, mais le fait de pouvoir mettre un typage fort avec un type mixed par défaut, sans l'auto-conversion, serait très bien pour 3 cas :

Cas mineur : Lorsque l'ont indique un type secondaire (Classe principalement), on pourrais posséder l'intellisense pour le choix des fonctions et variables de classes non-native à PHP dans les IDE.

Cas moyen : On pourrais enfin générer des fichiers de classes PHP grâce à l'UML qui marcherait directement avec le typage inscrit, sans avoir a tout modifier derriere .

Cas majeur : Permettre une surcharge (dynamique) des méthodes des classes en PHP (bye bye la fonction call_user_method ).

Code :

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

1
2
3
4
5
6
 
//Type mixed par défaut
function test( $a, $b ) {}
function test(int $a, int $b){}
function test(float $a, float $b){}
//Serais enfin 3 fonctions différentes

[Julien Breux]

Moi je pense que le typage faible fait la force de ce nouveau langage.

De plus, les variables extérieures sont retournées comme chaîne de caractères...

Donc difficile de faire:

Code :

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

1
2
3
$id = $_GET['id'];
 
function displayAuthorName(int $id){...}

(avec un typage fort)

[Yogui]

Justement, l'idée du typage fort est d'obliger le développeur qui utilise une API à forcer le type de ses variables. Puisque PHP a un typage faible, le type de la variable peut changer à tout moment, il faut donc "caster" à chaque utilisation de l'API :

Code :

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

function displayAuthorName(int $id){...}

Code :

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

1
2
3
$id = (int)$_GET['id'];
// ...
displayAuthorName((int)$id);