Êtes-vous pour ou contre les "strict type hints" ?

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:

---

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:

---

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

---

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

Code:

---

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:

---

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

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.

Code:

---

1 2 3 4

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

---

Oki cependant

Code:

---

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 !

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

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:

---

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:

---

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.

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

Code:

---

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.

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? 8O

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

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 :oops:

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

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

Citation:

---

Envoyé par doctorrock

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.

Citation:

---

Envoyé par doctorrock

Si je pouvais avoir une structure du type

Code:

---

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.

Citation:

---

Envoyé par Er3van

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

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 :D) par exemple comme le typage faible de php :P

Citation:

---

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

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

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

Citation:

---

Envoyé par savageman86

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

---

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:

---

1 2 3

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

---

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 :D).

Code:

---

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

---

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:

---

1 2 3

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

---

(avec un typage fort)

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:

---

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

---

Code:

---

1 2 3

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

---

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

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

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

Citation:

---

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)

---

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

Citation:

---

Envoyé par 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..

---

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

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

Par exemple, si je code

Code:

---

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:

---

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:

---

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

---

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

Citation:

---

Envoyé par Yogui

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

Code:

---

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 !

@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 :cry:

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

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

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

Code:

---

$maVariable=(int)$maVariable;

---

Ca faciliterais pas mal la lecture

Bonjour toutes et tous :D

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

Citation:

---

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

---

Affichera 13 bien sur ... 8O

@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
:yaisse2:

Citation:

---

Envoyé par Yogui

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 :D

Merci de ta réponse.

Citation:

---

Envoyé par FoxLeRenard

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 )

Citation:

---

Envoyé par BobLunique

Avec mysql :

SELECT 10+"20 PETIT ";

donne 30 ;)


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

( erreur de syntaxe )

---

Oui belle démonstration :king:

Citation:

---

Envoyé par FoxLeRenard

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.

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

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

Citation:

---

Envoyé par Yogui

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 ?

Citation:

---

Envoyé par aityahia

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.