[PHP 5.3] Countable et Empty : bug ou feature ?

[Halleck]

Bonjour tout le monde,

petite question de fond qui me chagrine :

Code php :

1
2
3
4
5
6
7
8
9
10
class Test implements Countable {
    public function count() {
        return 0;
    }
}
$o = new Test;
var_dump(sizeof($o));
var_dump(empty($o));
//int 0
// boolean false

Ce code fait l'objet de nombreux débats avec mes collègues.

Avis 1 :
Countable n'est qu'une interface qui permet d'utiliser sizeof/count. Il est normal que empty, dans la mesure où l'objet est un tableau, retourne false. Après tout, un objet est un objet, empty n'a pas la vocation à tester des objets complexe

Avis2 :
Countable fait partie des interfaces qui permettent de manipuler des objets comme des tableaux (pour arriver par exemple à la classe ArrayIterator). C'est donc qu'il y a une réelle volonté du language de pouvoir s'affranchir de la différence tableau/objet, facilement. Or dans ce cas, on est obligés de faire un test de type:

Code :

$empty = (is_object($o) && ($o instanceof Countable)) ? sizeof($o) > 0: empty($o);

Ce qui perd de son sens si on veut s'affranchir de la différence tableau/objet qui hérite de ArrayIterator
Dans ce cas, le code source d'empty devrait être revu pour gérer les objets qui implémentent Countable.

A votre avis:
Bref, si oui empty() est un peu une fonction "bâtarde" (peu fiable, par exemple si on teste une chaine "0"), est-ce qu'il faut revoir la fonction empty() à votre avis, ou bien est normal, conceptuellement, de ne pas utiliser un objet comme un tableau ?

[stealth35]

Y'a rien de choquant la dedans, c'est marqué en gros dans la doc :

PHP 5

Depuis PHP 5, les objets n'ayant pas de propriété ne sont plus considérés comme vide.

Countable n'implement que count, pusique count ne marche pas sur les object et revoie toujours 1
le code basique serait :

Code :

1
2
3
4
5
6
7
class Test implements Countable
{
    public function count()
    {
        return count(get_object_vars($this));
    }
}

en aucun cas il n'est question de conversion ou d'accès en Array, d'ailleurs c'est pas ArrayIterator mais ArrayAccess

pour le test un is_object + get_object_vars suffis dans n'importe quelle cas

[Benjamin Delespierre]

C'est une question épineuse, mais ce n'est pas un cas isolé. J'aime bien lire et relire cet article qui fait le tour de la question: http://blog.roshambo.org/20-possible...ers-are-weird/

Concernant sa fiabilité, je te renvoie vers un autre article: http://11heavens.com/true-or-false-in-php

Pour moi, utiliser un objet comme un tableau n'est pas vraiment une erreur mais ce n'est pas non plus nécessaire. Dès lors qu'un objet est traversable, on a ce qu'on voulait au final, si on peut lui coller un iterateur par dessus c'est encore mieux. L'adresser comme un tableau, personnellement je suis plutôt contre, je préfère l'usage de __get et __set pour les utiliser comme des structures.

On en parlait avec un collègue, les tableaux sont-ils des tree ? des hashmaps ? Un peu des deux ? Le comportement étrange des tableaux natif en PHP qui les faits se comporter comme des piles, des files, des listes chainées, des iterateurs etc. rends ce type de données obscur. Je lui préfère largement un modèle objet cohérent où chaque classe fait son job: SplStack, Iterator, SplQueue etc.

Quand à empty, chez moi ça se limite à isEmpty()