T'es sûr que le code est quand même exécuté ? C'est pas une sorte de catch par défaut ? Parce que si c'est dans les cas, où est l'intérêt ?

Sinon je sais que c'est en C++ qu'il n'y en a pas, mais en Java, il aurait pu utiliser ce fonctionnement par derrière, à travers le mot-clé finally justement …

J'en suis sûr (je viens de vérifier). En fait, c'est pour garantir la libération des ressources qu'il y ait eu ou non une excetption.

Et pour éviter les copier-coller :

try {
  code1;
  code2avecErreur;
  code3;
} catch (Exception $e) {
  log;
  code3;
}

// devient

try {
  code1;
  code2avecErreur;
} catch (Exception $e) {
  log;
} finally {
  code3;
}

D.R.Y.

plutôt K.I.S.S., je dirais. En tout cas, c'est green.

Au temps pour moi, mais ce n'est pas vital en tout cas .

Polymorphisme : tu peux être plus clair ?

exemple : on ne peux pas définir 2 fonctions ayant le même noms
-> mafonction()
-> mafonction($a,....)

Je trouve dommage que l'on n'ai pas cette possibilité en natif!

Attention: on peut le faire en interne en comptant les arguments mais c'est quelque chose de très moche!

Espace de noms : oui, c'est tout bon (sauf \, mais bon, il fallait faire un choix Smile).

Je pense que tout le monde partage le même avis! mais on ne va pas s'en plaindre.

Pour les erreurs : voir set_error_handler() et set_exception_handler().

Merci bcp, je connaissais pour exception mais pas pour error! Comme quoi on apprend tous les jours!

Laurent

Attention, comme je le présentais, tu confonds le polymorphisme et le typage de fonction/méthode.

Le polymorphisme permet d'avoir plusieurs définitions dans la hiérarchie des classes. On peut parler de surcharge mais parfois à tord … Donc par exemple : classe A et sa fille B. A a une méthode hello(). Sa fille hérite de la méthode hello(), mais peut la redéfinir. Si on travaille sur A, on aura un comportement (une forme), si on travaille sur B, on aura un autre comportement (une autre forme). Plusieurs formes, donc polymorphisme. Cette notion est encore plus forte avec l'abstraction ou l'interfaçage (voir classe abstraite et interface) qui permet — dans le cas d'interface — un polymorphisme sans héritage.

Le typage de fonction permet d'identifier une fonction (en partie, c'est plus large que ça, mais on se cantonne à cette sous-définition) par son en-tête. Donc la liste des paramètres à son importance. Ainsi, deux fonctions avec le même nom, même type de retour, mais avec des paramètres différents, n'auront pas la même signature/en-tête et donc seront différentes. C'est la liaison dynamique (du moins en objet, pour un langage fonctionnel je ne suis plus sûr ) qui va déterminer quelle fonction appeler.

Si j'ai bien compris , ce code doit fonctionner ? ( Comme en C++ par exemple )

class test{
	
	function testA(){
		echo "TestA1";
	}
	
	function testA(integer $a, integer $b){
		echo "TestA2";
	}
	
}

$p = new test();

$p->testA();
$p->testA(1,2);

Mais j'ai droit à un Fatal error ...

Normal d'apres la doc : PHP ne supporte pas le surchargement de fonction, ni la destruction ou la redéfinition de fonctions déjà déclarées.

Il y a moyen de faire autrement ?

PHP ne supporte pas le typage de fonction justement.

En revanche, tu peux t'en sortir avec les valeurs par défaut et ce genre de chose.
De plus, PHP a un typage dynamique faible, comprendre non déclaré et permettant des conversions implicites fortes. Comme c'est un typage dynamique, on ne filtre pas les données des arguments (excepté pour les tableaux et les objets). Ainsi :

class Test {

    // Bien.
    public function f ( $a, $b = null ) { }

    // Pas bien.
    public function f ( ) { }

    // Pas bien.
    public function g ( integer $a ) { } // sauf si integer est un objet !

    // Bien.
    public function h ( Array $a ) { }

    // Bien.
    public function i ( StdClass $a ) { }
}

On notera que — comme la plupart des langages à type dynamique — PHP ne supporte pas le typage de fonction, et ça se comprend bien …

Ce n'est pas bien de vouloir typer un argument d'une fonction ?

Pour être certain d'avoir un entier par exemple ? que ce soit dans une classe , abstraite, une interface , ou traits bientot ?

J'ai toujours pensé que plus c'était restrictif , mieux c'était ...

Ce n'est parce que PHP ne fait pas quelque chose que c'est mauvais . C'est une autre philosophie, une autre approche.

Disons qu'au début, tu avais que des langages non typés. On s'est rendu compte que niveau sécurité, c'était pas ultra top, donc on est passé aux langages typés. On trouve grosso modo trois familles : les types statiques, les types dynamiques et les types inférés. Chacun a une approche différente, des avantages et des inconvénients. Personnellement, j'ai un faible pour le typage inféré . (Je laisse volontairement les types faibles et forts de côté).

Pour comparer rapidement les deux premiers (car ce sont ceux qui nous intéresses présentement), on pourrait dire que la différence est que pour un typage statique, le type porte sur la donnée, alors que pour un typage dynamique, le type porte le contenu de la donnée. Par exemple : en C, on écrirait int x;, donc x ne peut contenir que des entiers, alors qu'en PHP on écrirait $x; et si x contient un entier, alors il sera typé comme un entier. C'est dynamique, c'est connu à l'exécution.

Si les deux philosophies existent encore aujourd'hui, c'est qu'elles apportent chacune quelque chose. Il n'y a donc pas de mieux ou de moins bien, ça dépend du contexte d'utilisation. Et pour PHP, c'est très utile .

Ba voilà .. j'ai encore appris un truc ce soir ...

Vivement demain ..

Merci pour ces précisions ...

Ch.

pour un typage statique, le type porte sur la donnée

Sur la variable, sinon c'est plus dur à comprendre.

Les type hint sont en discussion/développement, donc, il faudra patienté un peu

Euh, à quoi ça sert goto ?

Les goto ont été inventé avec les premiers language (j'en faisais sous PASCAL). Tu faisais si condition est vrai (ou fausse) alors va plus (go to : va vers) bas ou plus haut dans le script. Le problème est que les scripts devenait hyper lourds, avec souvent des bug de boucles redondantes (on peut pas tout prévoir) : un goto infini quoi.