php __autoload

[php_addict]

Bonjour

pour les codeurs php, utilisez vous l'autoload systématiquement ou juste comme précaution si vous avez oublié un include('MaClass.php') ?

et utiliser vous les namespace, ou la version oldschool, c'est à dire Ma_Class pour Ma/Class ?

des conseils sur l'autoload?


Ps: Vous allez me dire que c'est naze, mais je suis en train de revoir mes models et les structurer en class plutot qu'en procedural. Bon ok je n'utilise pas le concept d'objet, juste l'encapsulation...je déteste le concept objet, surtout qu'en php a POO a l'air un peu pourrie...

bonne journée

[Sephi-Chan]

pour les codeurs php, utilisez vous l'autoload systématiquement ou juste comme précaution si vous avez oublié un include('MaClass.php') ?

et utiliser vous les namespace, ou la version oldschool, c'est à dire Ma_Class pour Ma/Class ?

des conseils sur l'autoload?


Ps: Vous allez me dire que c'est naze, mais je suis en train de revoir mes models et les structurer en class plutot qu'en procedural. Bon ok je n'utilise pas le concept d'objet, juste l'encapsulation...je déteste le concept objet, surtout qu'en php a POO a l'air un peu pourrie...

Autant utiliser l'autoload systématiquement en tirant profit des namespaces, puisque c'est ce qu'encourage PHP. Inutile d'apprendre des choses obsolètes.

Pour la non-utilisation du modèle objet, pourquoi pas. Les langages fonctionnels (Erlang, par exemple) permettent de définir des fonctions dans des modules, histoire de les ranger par thème. Tu peux faire la même chose en PHP en créant des classes contenant des méthodes statiques : les appels sont laids (Foo::bar()), mais ça marche bien.

Du coup, quelles structures vas-tu utiliser pour représenter tes entités ? Des hashes (tableaux associatifs) ?

Cette approche me paraît plutôt saine (même si PHP n'est pas vraiment armé pour faire du pseudo fonctionnel), d'autant que ça permet d'avoir du code stateless, donc facile à tester unitairement.


Par contre, je suis curieux de savoir sur quoi tu te bases pour dire que la POO de PHP te semble pourrie.

[Ter Rowan]

Par contre, je suis curieux de savoir sur quoi tu te bases pour dire que la POO de PHP te semble pourrie.

pareil

[Xenos]

La POO de PHP est "pourrie" au sens qu'il n'y a pas certaines composantes pratiques, come:
- Les typages
- La redéfinition d'opérateurs (c'est moche ces "add($obj1, $obj2);"...)
- La surcharge par typage (fonction(string $var) surchargée par fonction(int $var))

Perso, je n'utilise pas le auto-load, par habitude issue du C/C++.

[srm]

Donc la POO PHP est pourris parce que :
- le langage n'est pas typé
- on peut pas surcharger les opérateurs

Ok...
D'ailleurs la POO C/C++ est pourris parce que :
- le langage est typé
- on peut surcharger les opérateurs

[niahoo]

es appels sont laids (Foo::bar()), mais ça marche bien.

Les appels de cette forme ne sont pas laids, enfin moi j'aime bien

La syntaxe d'erlang n'est pas orientée objet dans le sens ou on ne mélange pas les données et les fonctions qui s'appliquent sur les données.

Cependant, Erlang est le seul langage avec lequel je trouve que faire de l'objet est vraiment agréable, dans le sens architecture et pas syntaxic sugar de luxe. Pour ceux que ça intéresse : the State of OOP - erlang est-il le seul langage orienté objet ?

En php un objet c'est une bête struct globale qui est passée dans une variable obfusquée (this) à des méthodes associées à cette structure ou à une structure parente. Y a pas plus que ça. D'ailleurs, en php y a un genre de convention qui veut qu'on préfixe d'un underscore les variables privée. C'est-y-pas stupide quand même comme convention ? L'underscore devrait être utilisé comme en python c'est 10 fois plus malin. Mais bon, la syntaxe d'Erlang permet aussi de faire des méthodes privées ou publiques, ça n'a rien à voir avec de l'objet

Mais les méthodes magiques et les array de php permettent de faire du code simple et très fonctionnel.


Allez, la question sephi : tant qu'à recoder une bonne partie de ton appli, pourquoi ne pas utiliser un framework pour guider tes pas et raccourcir ton code ? D'autant plus qu'un bon framework te laissera utiliser la lib que tu veux pour tes modèles, si tu veux les faire en procédural. Et les contrôleurs ne sont que des groupes de callbacks, donc de simples fonctions.

[php_addict]

Du coup, quelles structures vas-tu utiliser pour représenter tes entités ? Des hashes (tableaux associatifs) ?

un truc du genre:

function __autoload($class)

{

    $path = str_replace('_', DIRECTORY_SEPARATOR, $class);

    require_once($path . '.php');

}

et il faut faire gaffe à l'emplacement des classes et des noms de fichiers

par contre à priori il vaut mieux utiliser spl_autoload mais j'ai pas bien compris pourquoi à vria dire...

Par contre, je suis curieux de savoir sur quoi tu te bases pour dire que la POO de PHP te semble pourrie.

je rajouterais que tu peut pas étendre une classe à plusieurs classes, un truc du genre:

Class Joueur Extend Profil , Supprimer, Attaquer

il me semble que cela est possible dans d'autres langages non? (y a des bidouille apparement en php mais c'est pourri)


EDIT:

par contre l'__autoload semble quand même affecter la vitesse d'execution des scripts qui en php est déjà pas terrible...

[niahoo]

L'héritage multiple c'est pas forcément une super feature. Le concept de traits et l'injection de dépendances suffisent généralement à faire ce qu'il apporte, sans les ennuis.

M'enfin bon vu que tu ne fais pas d'objet c'est pas l'héritage multiple qui va te manquer quand tu t'y mettras ni dans les années suivantes. Après ça tu auras changé de langage :p

[Holy]

par contre l'__autoload semble quand même affecter la vitesse d'execution des scripts qui en php est déjà pas terrible...

L'autoload affecte la vitesse d'execution, mais c'est valable pour tous les langages non compilés à priori.

Par ailleurs, PHP n'est pas moins performant que Ruby ou n'importe quel autre langage orienté web (ou à tout le moins rien de fondamentalement significatif). Je sais pas où tu as lu ça. Les faiblesses de PHP tiennent davantage à son historique qu'à ses performances intrinsèques. PHP aurait tout à gagner à produire une nouvelle version où la compatibilité ascendante n'est pas assumée et où les conventions syntaxiques seraient revues et normalisées. Même dans le core de PHP il y a des incohérences de casses par exemple, ce qui est assez pénible.

[Sephi-Chan]

Du coup, quelles structures vas-tu utiliser pour représenter tes entités ? Des hashes (tableaux associatifs) ?

un truc du genre:

function __autoload($class)

{

    $path = str_replace('_', DIRECTORY_SEPARATOR, $class);

    require_once($path . '.php');

}

Non, ma question c'est : Quelles structures vas-tu utiliser pour représenter les entités (joueurs, personnages, etc.) que tu vas stocker et extraire de ta base de données ?

Par contre, je suis curieux de savoir sur quoi tu te bases pour dire que la POO de PHP te semble pourrie.

je rajouterais que tu peut pas étendre une classe à plusieurs classes, un truc du genre:

L'héritage multiple est plutôt une mauvaise fonctionnalité dont personne ne veut (en dehors de C++) : elle apporte plus de problèmes que de solutions. En général, on favorise la composition par rapport à l'héritage. De toute façon, vu que tu ne comptes pas faire d'OO, cela ne te concerne pas vraiment.

par contre l'__autoload semble quand même affecter la vitesse d'execution des scripts qui en php est déjà pas terrible...

Les langages interprétés sont des veaux, mais ça n'empêche pas d'avoir des applications qui répondent assez vite. À l'inverse, langages performants (Java, par exemple) ont tendance à avoir des stacks Web affreuses qui rendent les applications molles. ^^