Discussion :

[rebolon]

Salut,

J'avais déjà dû le voir, mais maintenant ça me choque.
Imaginons :
une interface "say" qui déclare une méthode "hello".
une classe "behavior" qui implémente cette interface et qui déclare aussi une méthode public "byebye"
une classe "person" qui a une propriété "protected $_behavior" et un setter "public function setBehavior(say $behaviorSay)" et un getter "public function getBehavior()"

A votre avis, dans setBehavior() qu'est ce que je peux faire ?

tic, tac, tic, tac
attention l'heure tourne.

petit indice je fais un print_r/var_dump sur $behavior et PHP va m'afficher "behavior Object()"

tic, tac, tic, tac

Et bien, PHP m'autorise à utiliser la méthode "byebye" alors même qu'elle n'est pas déclarée dans l'interface "say".

Perso, ça me semble anormal car ça permet aux développeurs de faire ce qu'ils veulent dès lors que c'est public et ce, même si on a tenté de brider via un typage de paramètre. Evidemment je sais qu'on ne peut pas typer une propriété, du coup quand on appel le getter getBehavior(), je sais que j'aurais accès à tous ce qui est public dans l'objet qui a été injecté (au niveau de l'IDE si les commentaires sont bons on peut ~typer la propriété et brider l'autocomplétion proposé). Mais quand cela est possible aussi dans la méthode qui n'est censé utiliser que l'implémentation de l'interface, là ça me gène.

Je suis seul à penser ça ? j'ai raté quelque chose ? je me pose trop de question ? je me pose les mauvaises questions ?

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
26
27
28
29
30
31
32
33
34
35
 
interface say {
    public function hello();
};
 
interface move {
    public function walk();
}
 
class behavior implements say, move{
    public function hello(){echo 'hello';}
    public function byebye(){echo 'bye bye';}
    public function walk(){echo 'i am walking';}
};
 
$a = new behavior;
 
class person {
    /**
     * permet de brider l'auto-complétion de l'IDE sur les méthodes disponibles dans l'interface say
     * @var say
     */
    protected $_behavior;
    public function setBehavior(say $behavior){ 
        $this->_behavior = $behavior; 
 
        // ne devrait pas être accessible
        $behavior->byebye() ou $behavior->walk(); // ceci est autorisé en php alors que cette méthode n'est pas déclarée dans l'interface say
    }
 
    // on ne peut pas typer une propriété, du coup il est normal que cet getter permette ensuite d'accéder aux méthodes byebye et walk puisque de manière dynamique on a stocker un objet de type behavior
    public function getBehavior() { 
        return $this->_behavior; 
    }
}

PS : c'est la même chose si on utilise une classe abstraite et que l'on se sert de cette classe pour typer le paramètre : c'est le type de l'objet qui prime.
Du coup le typage des paramètres sert à controller le type au niveau de l'entré alors qu'il devrait permettre également de controller l'utilisation de l'objet au sein de la méthode.

[rawsrc]

Bonjour,

Et bien, PHP m'autorise à utiliser la méthode "byebye" alors même qu'elle n'est pas déclarée dans l'interface "say".

Je ne vois pas où est le problème. Une interface est un contrat, donc l'interface say te garantit qu'au minimum, les classes l'implémentant rempliront le contrat. Il n'y a aucune autre notion attachée.
Donc après, si dans le corps de ta fonction tu appelles une fonction qui n'a rien à voir avec l'interface implémentée, c'est à tes risques et périls, rien ne peut te garantir effectivement que la fonction sera disponible.

[rawsrc]

Après il est tout à fait possible d'étendre une interface :

Code :

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

1
2
3
4
5
6
7
8
9
interface say {
   public function hello();
};
 
interface sayAndMove
   extends say
{
   public function walk();
}

[rebolon]

Ce qui me dérange c'est que la méthode puisse utiliser n'importe quelles méthodes public de l'objet passé. Le problème ? dans ce cas si ma méthode est utilisé à différents endroits ou dans différents projets et que les objets passés dans ces cas n'ont pas les fameuses méthodes public non déclarées dans l'interface, et bien ça va planter.

Sauf erreur de ma part en Java ou dotNet on a accès uniquement aux méthodes déclarées dans l'interface.

Bizarrement j'ai l'impression que ça fonctionnait comme ça, mais il est bien possible que je confonde avec d'autres langages.
Dans le bouquin PHP Objects, Patterns, and Practice (édition APRESS) page 47/48 ils disent bien que la méthode n'a connaissance que des méthodes déclarées dans l'interface... Mais en fait elle a accès à beaucoup plus.

Après si on veut utiliser la reflection, pour accéder à plus, on est libre de faire ce qu'on veut, mais dans ce cadre bien défini.

[rebolon]

D'accord avec l'héritage d'interface, mais ça ne modifie en rien la problématique.
Autant supprimer les interfaces et typer avec la classe. Toute classe héritant de celle-ci seront autorisées (mais on a un couplage fort que les interfaces permettent d'éviter).

[rawsrc]

Dans le bouquin PHP Objects, Patterns, and Practice (édition APRESS) page 47/48 ils disent bien que la méthode n'a connaissance que des méthodes déclarées dans l'interface... Mais en fait elle a accès à beaucoup plus.

Oui tu as accès à la totalité de l'instance passée en paramètre.

Après si on veut utiliser la reflection, pour accéder à plus, on est libre de faire ce qu'on veut, mais dans ce cadre bien défini.

C'est pas la solution optimale dans la mesure où la réflection est lente et assez gourmande.

[rebolon]

Encore d'accord avec toi avec la Reflection, c'était juste pour dire que dans le principe où on aurait accès qu'aux méthodes de l'interface, la Reflection permettrait quand à ceux qui le souhaitent d'accéder au reste de l'instance envoyé.

Au final c'est peut être un faux problème. Dans mon code je n'utilise que ce qui est proposé par l'interface (ou les classes abstraites, au pire)...

[stealth35]

Quel est l’intérêt de faire du PHP si tu veux du typage fort ?

[rebolon]

Industrialiser mes dév !
Eviter les régressions, même en PHP, c'est un truc sympa.

Plus sérieusement, on peut vouloir du typage fort dans PHP parce que c'est simplement la plateforme sur laquelle on travaille. Mais cela n'empêche pas non plus d'utiliser les propriétés dynamiques de PHP.

Attention, j'aime bien PHP, je dis juste que si PHP permet de typer les paramètres, autant qu'il respecte certains principe. Et, tant qu'à faire, autant que les bouquins évitent d'écrire des bêtises.

[rebolon]

J'ajoute que les frameworks (Zend, Sf2...) sont tous fortement typés, pourtant ils sont en PHP

[stealth35]

J'ajoute que les frameworks (Zend, Sf2...) sont tous fortement typés, pourtant ils sont en PHP

Non, c'est pareil, les propriété et le retour des méthode ne le sont pas, et y'a que 2 typehinting pour les méthode : array et object (et callable avec 5.4), tu peux pas mettre string ou int, cette impression de type fort n'est que du à la doc

[rebolon]

Non, c'est pareil, les propriété et le retour des méthode ne le sont pas, et y'a que 2 typehinting pour les méthode : array et object (et callable avec 5.4), tu peux pas mettre string ou int, cette impression de type fort n'est que du à la doc

Pour moi ce n'est pas pareil, mais c'est en partie ça la cause : pas de typage sur les retours, ni sur les propriétés. Peut-être une future évolution du langage. D'ailleurs cela n'empêcherai pas une cohabitation avec les types dynamiques.
Je trouve juste intéressant dans le cadre du développement d'un framework d'utiliser du typage fort. Que l'utilisation de cellui-ci se fasse au sein de projet qui font du dynamique ne me choque pas.

Après l'auto-complétion de l'IDE ne proposera que ce que déclare l'interface. Mais on là, le langage se repose alors sur les services proposés par les outils ce que je trouve étrange.

[stealth35]

Après il est tout à fait possible d'étendre une interface :

Code :

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

1
2
3
4
5
6
7
8
9
interface say {
   public function hello();
};
 
interface sayAndMove
   extends say
{
   public function walk();
}

on peut même faire plusieurs extends (ça marche que pour les interfaces)

Code :

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

interface sayAndMove extends say, hello, blabla

[rebolon]

Je précise le côté " ce n'est pas pareil" :
dans le cadre du typage des paramètres on est dans le cadre de la portée des variables.
alors que dans les retours et les propriétés on est dans le typage fort d'un language

[stealth35]

Pour moi ce n'est pas pareil, mais c'est en partie ça la cause : pas de typage sur les retours, ni sur les propriétés. Peut-être une future évolution du langage. D'ailleurs cela n'empêcherai pas une cohabitation avec les types dynamiques.
Je trouve juste intéressant dans le cadre du développement d'un framework d'utiliser du typage fort. Que l'utilisation de cellui-ci se fasse au sein de projet qui font du dynamique ne me choque pas.

Après l'auto-complétion de l'IDE ne proposera que ce que déclare l'interface. Mais on là, le langage se repose alors sur les services proposés par les outils ce que je trouve étrange.

C'est que je dis, c'est uniquement lié au docblock, donc pas au langage lui même, je serai pas non plus contre avec un typage un peu plus fort, on peux toujours utilise SPL Type mais bon ...
y'a aussi le projet de faire une méthode magic pour la casting, pour le moment on a que __toString

https://wiki.php.net/rfc/class_casting_to_scalar
https://wiki.php.net/rfc/object_cast_to_types

mais utiles uniquement pour les fonctions/méthodes native (ou d'extension)

[rebolon]

Tout à fait d'accord.
Merci pour la discussion :-)

[stealth35]

Après si tu regardes dans les sources de PHP, les erreur de type se font direct dans les fonctions, c'est que j'ai mis dans le mysql_prepare

[rebolon]

ok, j'y jetterai un coup d'oeil (j'avais jamais eu l'occas de regarder les sources PHP, ça tombe bien)