SPIP, avec PEAR, a toujours été pour moi le symbole de ce qu'il ne faut pas faire en développement web. SPIP, effectivement parce que c'est écrit en Français, et parce que la sécurité n'a jamais été au cœur de la philosophie de développement. On se souviendra avec nostalgie des nombreux trolls qui ont accompagnés son existence.
Maintenant, tu viens nous parler d'une autre horreur qui s'impose dans le monde PHP : la Javaïfication. Si PHP a eu du succès, c'est entre autres parce que ça permet de faire des trucs assez dégueulasse, en peu de temps. Venir vouloir y imposer son ordre arbitraire, ce n'est pas forcément une bonne idée. Moi j'aime développer en orienté objet, donc j'écris des fonctions. Ça peut sembler bizarre à quelqu'un qui n'a jamais fait de C++, mais dans les véritables langages orientés objets, on considère que le polymorphisme n'est pas forcément une propriété liée à une classe (voir le polymorphisme statique apporté par les fonctions template).
Je n'aime pas PSR0 ou même PSR1. Tout d'abord, parce que ça contraint à faire du CamelCase illisble. Oui, je suis handicapé et j'ai toutes les difficultés à lire le CamelCase. Un peu comme j'ai du mal à lire du code dont les phrases s'allongent sur plus de 70 colonnes, avec plus de deux imbrications, et des fonctions de plus de deux pages. Et cette blague de l'autoload me défrise : quand on ouvre un fichier source, on doit connaître en première lecture ses dépendance par les fichiers qu'il requiert. Vouloir laisser ça au runtime est absurde.
Et puis, je n'ai pas envie d'un environnement où tout le monde fait la même chose. À quoi ça sert d'avoir 10.000 frameworks qui appliquent la même chose ? Dans le monde Python, il y a se genre de blague. Alors d'accord, Pylons, Bottle/Flask/Web.Py et Django se distinguent par une approche de séparation des responsabilité légèrement différente, ce sont trois conception assez différentes. Mais dans l'absolu, elles reposent toutes trois sur une même conception, sur le même design pattern (une chaîne de responsabilité). Dans le monde PHP, aujourd'hui, on a ce phénomène avec Zend, Symphony ou CodeIgniter. Quel est l'intérêt ?
Bref, je continuerais à écrire mon Framework avec des fonctions dans des namespaces, des fonctions en lower case avec des underscores, et des classes et des variables nommées selon la même logique. Parce que, oui, c'est plus joli comme ça.
[^] # Re: SPIP ?
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à -1.
SPIP, avec PEAR, a toujours été pour moi le symbole de ce qu'il ne faut pas faire en développement web. SPIP, effectivement parce que c'est écrit en Français, et parce que la sécurité n'a jamais été au cœur de la philosophie de développement. On se souviendra avec nostalgie des nombreux trolls qui ont accompagnés son existence.
Maintenant, tu viens nous parler d'une autre horreur qui s'impose dans le monde PHP : la Javaïfication. Si PHP a eu du succès, c'est entre autres parce que ça permet de faire des trucs assez dégueulasse, en peu de temps. Venir vouloir y imposer son ordre arbitraire, ce n'est pas forcément une bonne idée. Moi j'aime développer en orienté objet, donc j'écris des fonctions. Ça peut sembler bizarre à quelqu'un qui n'a jamais fait de C++, mais dans les véritables langages orientés objets, on considère que le polymorphisme n'est pas forcément une propriété liée à une classe (voir le polymorphisme statique apporté par les fonctions template).
Je n'aime pas PSR0 ou même PSR1. Tout d'abord, parce que ça contraint à faire du CamelCase illisble. Oui, je suis handicapé et j'ai toutes les difficultés à lire le CamelCase. Un peu comme j'ai du mal à lire du code dont les phrases s'allongent sur plus de 70 colonnes, avec plus de deux imbrications, et des fonctions de plus de deux pages. Et cette blague de l'autoload me défrise : quand on ouvre un fichier source, on doit connaître en première lecture ses dépendance par les fichiers qu'il requiert. Vouloir laisser ça au runtime est absurde.
Et puis, je n'ai pas envie d'un environnement où tout le monde fait la même chose. À quoi ça sert d'avoir 10.000 frameworks qui appliquent la même chose ? Dans le monde Python, il y a se genre de blague. Alors d'accord, Pylons, Bottle/Flask/Web.Py et Django se distinguent par une approche de séparation des responsabilité légèrement différente, ce sont trois conception assez différentes. Mais dans l'absolu, elles reposent toutes trois sur une même conception, sur le même design pattern (une chaîne de responsabilité). Dans le monde PHP, aujourd'hui, on a ce phénomène avec Zend, Symphony ou CodeIgniter. Quel est l'intérêt ?
Bref, je continuerais à écrire mon Framework avec des fonctions dans des namespaces, des fonctions en lower case avec des underscores, et des classes et des variables nommées selon la même logique. Parce que, oui, c'est plus joli comme ça.