Discussion :

[s.n.a.f.u]

Bonjour tous,

Je suis tombé sur un cas étrange alors que je gérais un objet en utilisant une variante du pattern Composite.

Dans le code suivant, j'arrive à accéder à une méthode privée du descendant à partir du parent. Comment cela s'explique-t-il ?

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
36
37
38
39
40
41
42
43
44
45
46
 
<?php
class composite {
 
    private $_name;
 
    protected $_children = array();
 
    public function __construct($name)
    {
        $this->_name = $name;
    }
 
    public function publicRecursiveStuff()
    {
        printf ('public : %s' . PHP_EOL, $this->_name);
 
        foreach ($this->_children as $c) {
            // !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
            // !! ACCES A UNE METHODE PRIVEE !!
            // !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
            $c->_privateRecursiveStuff();
        }
    }
 
    private function _privateRecursiveStuff()
    {
        printf ('private : %s' . PHP_EOL, $this->_name);
    }
 
    public function addChild($name)
    {
        $child = new composite($name);
        $this->_children[] = $child;
        return $this;
    }
}
 
// init de l'objet
$root = new composite('root');
 
// ajout de descendants
for ($i = 1; $i < 10; $i++) {
    $name = 'child' . $i;
    $root -> addChild($name);
}

J'imagine que c'est parce qu'il s'agit de la même classe, mais je ne trouve pas plus d'explications.

D'avance merci de vos lumières.

[stealth35]

L'accès aux éléments privés est uniquement réservé à la classe qui les a définis.

De plus il va aller chercher ses méthode.

Et surtout ca :

http://www.php.net/manual/fr/languag...-other-objects

Les objets de même type ont un accès aux membres privés et protégés même s'ils ne sont pas dans la même instance. Ceci est dû au fait que les détails spécifiques de l'implémentation sont déjà connus en interne par ces objets.

[Benjamin Delespierre]

On l'avait déjà relevé dans un autre thread mais c'est vrai que c'est assez déroutant... Enfin, pas tellement moins non plus qu'une méthode abstract protected static

Les bizarreries du langage n'arrêteront jamais de nous surprendre

[ThomasR]

Enfin, pas tellement moins non plus qu'une méthode abstract protected static

Bonjour Benjamin,

je ne vois pas de problème à forcer la définition d'une méthode statique et protégée. Ni d'un point de vue technique, ni d'un point de vue conceptuel. J'ai peut-être loupé le coche ?

[s.n.a.f.u]

Les objets de même type ont un accès aux membres privés et protégés même s'ils ne sont pas dans la même instance. Ceci est dû au fait que les détails spécifiques de l'implémentation sont déjà connus en interne par ces objets.

Ca m'en bouche un coin.
Quoi qu'il en soit, j'ai décider de ne pas utiliser cette technique, même si elle est la plus directe. Trop de prise de tête en perspective.

Quoi qu'il en soit, je vais me coucher moins con ce soir, et c'est déjà une belle performance !

[Benjamin Delespierre]

Bonjour Benjamin,

je ne vois pas de problème à forcer la définition d'une méthode statique et protégée. Ni d'un point de vue technique, ni d'un point de vue conceptuel. J'ai peut-être loupé le coche ?

Avec PHP 5.3 et le late static binding c'est vrai que c'est possible mais essayez ça pour voir:

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
abstract class A {
 
  // si vous voulez que ça marche, mettez static
  public static function say () { echo self::hello(); }
 
  abstract protected static function hello ();
 
}
 
class B extends A {
 
  protected static function hello () { return 'Say hello to peter'; }
 
}
 
B::say();

Cela provoque un

Code :

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

Strict standards: Static function A::hello() should not be abstract

[stealth35]

c'est normale, c'est pas logique de faire ça, puisqu’on ne sait pas a qui appartient la méthode, il faut utiliser une interface, ou les traits

[Benjamin Delespierre]

c'est normale, c'est pas logique de faire ça, puisqu’on ne sait pas a qui appartient la méthode, il faut utiliser une interface, ou les traits

Tout à fait, mais un tel code en C++ par exemple ne devrait même pas compiler. D'ou l'aspect "étrange" de certains points du langages comme le late static binding qui permet de contourner ça.

[stealth35]

Tout à fait, mais un tel code en C++ par exemple ne devrait même pas compiler. D'ou l'aspect "étrange" de certains points du langages comme le late static binding qui permet de contourner ça.

c'est parce que avant tu pouvais le faire