Hey !

Peux tu me donner quelques liens sur les IDL ?
J'ai un peu de mal a trouver de la documentation et à voir ce que c'est.

Merci

Bon, l'idée que j'ai en tête et de virer la documentation API (http://hoa-project.net/Manuel/Api/) et de la remplacer par des IDL.
On écrit notre IDL, on la compile, on a notre code PHP qui est déjà prêt. On a juste à remplir les petits trous.
Mozilla utilise les IDL par exemple pour XPCOM. Le W3C s'en sert pour ses doc API. Ça sert d'interface en quelque sorte, l'équivalent des .h en C si vous préférez. Un exemple : http://mozilla.hoa-project.net/Aquila/s … Finder.idl. L'idée est d'abstraire les interfaces des objets (comprendre, les prototypes, les profils, les en-têtes etc.).
Attention, XPIDL c'est le binaire universel utilisé par XPCOM provenant des IDL. C'est encore autre chose. Nous on compilerait l'IDL en code PHP. Du coup, on écrit notre IDL, on compile, on obtient un beau fichier PHP déjà tout beau tout propre. On a juste à écrire le corps de nos méthodes (et encore). Ça fait gagner du temps en développement ça permet que tout le monde code de la même façon quand il contribue au projet, et … ça permettrait d'avoir des interfaces partagées. On aurait juste à recompiler une IDL pour changer les interfaces de plusieurs paquetages.

Mais ça nécessite un compilateur, et j'en ai marre d'en faire .
Bref, c'est pas compliqué, mais faut étudier l'utilité pour ne pas perdre du temps. Ça peut être un foirage totale malgré le fait que ça paraisse séduisant.

Bien, je donne mes impressions sur le code.
Je dissèque tout ça.

Exception.php

Tu as écrit :

class Hoa_VideoPlayer_Exception extends Hoa_Exception {

    public function __construct ( $message=null, $code=0, $arg=array() ) {

        parent::__construct($message, $code, $arg);
    }

}

Bel essai, mais ça revient à écrire :

class Hoa_VideoPlayer_Exception extends Hoa_Exception { }

tout simplement . C'est plus rapide, plus léger et plus facile à maintenir.

VideoPlayer.php

Je vois que le paramétrage des paquetages n'est pas une notion facile dans Hoa. Je vais travailler ça pour faire un système plus propre.

Tu fais des importations dans les méthodes … Hmm, on va éviter de faire comme ça. Je comprends pourquoi tu le fais, tu veux avoir une importation « dynamique » :

import('VideoPlayer.Server.'.self::getServerName());

Ce qui est bon de faire dans ce cas, c'est une fabrique (voir Hoa_Factory). C'est plus propre, et ça te permet d'avoir tes importations en début de fichier. C'est la convention qui veut ça. Surtout que les fichiers ne seront importés que si nécessaire ; on a une importation tardive ou un pré-chargement pour respecter la terminologie de Hoa (voir Pré-chargement ou couplage import et auto-chargement). Et utiliser une fabrique t'évitera le code qui suit :

$className = 'Hoa_VideoPlayer_Server_'.self::getServerName();
$this->server = new $className($this->param['server']);

Bref, tu y gagneras.

Pourquoi avoir la méthode arrayMergeRecursive (qui d'ailleurs n'a pas besoin d'être privé) ? Tu as array_merge_recursive.

Server/Abstract.php

On écrit en général la méthode __toString à la fin de la classe.

Tu répètes arrayMergeRecursive, ce n'est pas bon.

Player/???.php

Ç'eut été bien d'avoir Video.php, l'élément natif <video> de l'HTML 5. Car bon, le Flash, wala quoi …

Parser/*.php

Tu sais que le paquetage Hoa_Uri existe ? Ah oui mince … il n'est pas documenté. Shame on me!

Remarques générales

Attention aux caractères de fin de ligne. J'ai du faire un petit :%s/^M//g dans tous les fichiers (voir format de fichier dans le manuel).

Tu as tendance à mettre les attributs en visibilité publique. La philosophie de Hoa tendrait à ce qu'on les place dans une visibilité protégée.

Tu as également tendance à donner des noms de variables raccourcis (je pense à param par exemple). On donnera toujours des noms complets (donc parameter), et on fera attention au singulier et pluriel (donc parameters avec notre exemple).

Au passage, les espacements ne sont pas bons. Tu as écrit parfois :

public function __construct ( $param=null ) {

On écrirait plutôt :

public function __construct ( $parameters = array() ) {

(oui, un tableau vide par défaut, ça t'évite le test de nullité).
Pareil avec les signes = qui ne sont pas alignés dans le corps des méthodes ou des attributs.

On préfère utiliser && et || plutôt que AND et OR. On ne les utilise pas avec la même philosophie. En général, les mots-clés sont utilisés pour du code en-ligne (inline), comme la définition des constantes dans Framework.php. Les opérateurs sont utilisés pour les expressions logiques dans le reste du code.
Grosso modo :

f(…) and g(…);
if($foo && $bar) {

Au passage, les mots-clés ont une précédence plus faible que les opérateurs. Attention à des comportements non-prévus.

Les lignes font plus de 80 caractères (voir Espacement et longueur de ligne).

Attention aux sauts de lignes inutiles. Par exemple, en fin de classe :

    }

}

Plutôt :

    }
}

En fait, les accolades ne sont pas toujours bien espacées aussi.

Attention, parfois tu as des doubles point-virgules (par exemple : Parser/Abstract.php, ligne 105).

Conclusion

Le code est pas mal. Tu as bien abstrait les choses mais je pense qu'on peut faire mieux (on peut toujours faire mieux remarque).
J'approfondis mes réflexions sur les IDL et les assistants ou les composants de la couche vue. On verra comment intégrer ton code à ce moment là.
En attendant, tu peux corriger ton code en fonction de mes remarques et revenir avec une nouvelle version .

Encore merci pour ta participation !

Pour __toString, c'est marqué nul part, c'est juste la convention adoptée dans Hoa. Ça ne concerne pas vraiment l'objet, c'est juste une autre visualisation de l'objet, donc on peut le mettre en bas. On sait que les méthodes __toString sont toujours les dernières ou avant-dernières (dans ce cas, la dernière est __destruct ou une méthode de clotûre).

Pour le format de fichier : si tu es en CRLF et que j'ouvre ton fichier sur un système Unix, je vais voir apparaître ^M, soit CR. C'est mal, inutile et ça alourdit le fichier pour rien (car inutile sous Unix).
Donc, comme j'édite mes fichiers en binaires avec Vim, je vois ce caractère. Donc j'ai remplacé ce caractère : %s/^M//g (Ctrl + v, M pour écrire ce caractère) dans le fichier. Et comme tous les fichiers étaient dans le même état, j'ai sorti sed :

$ sed -i '' -e 's/^M//g' **/*.php

Et non, je n'ai pas d'outils. Seulement mes petites mimines .