[AlternC-dev] Discussion sur alternc v2

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Dominique Rousseau d.rousseau at nnx.com
Jeu 7 Déc 15:42:54 CET 2006


Le Thu, Dec 07, 2006 at 02:34:03PM +0100, Nil [nicolist at limare.net] a écrit:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> >> python ne serait-il pas plus indiqué, pour les raisons suivantes: *
> >> gestion des classes un ordre de grandeur (au moins) supérieure aux
> >> classes dans php
> > 
> > Moui. PHP5 a grandement amélioré les choses, quand même.
> 
> Peut-être. Euh, on est parti sur du php5 strict, là?

Ca peut être une contrainte à poser. Pas plus contraignante qu'un
changement de syntaxe de langage.

> Mais en python, la notion d'objet est naturelle, dès la base du
> language, avec des namespace imbriques proprement et en plein de
> niveau. En php, on fait de l'objet ou pas; et en général on fait pas.
> En python, on fait toujours de l'objet, comme M. Jourdain fait de la
> prose, qu'on le veuille ou non.

Bof. On peut faire du code tout procédural, sans utiliser les syntaxes
objet.

> Depuis le début, et amélioré depuis python 2.2.
> 
> Ah oui, aussi... en python, les exception, ca existe. Du coup, la
> gestion d'erreurs, bah... c'est normal quoi.

PHP5 aussi :)

> >> * test, documentation et contrôle de la qualité ces fonctionnalités
> >> sont intégrées ou faciles à utiliser -> doctest, unittest, pylint,
> >> pychecker, etc.
> > 
> > doxygen fonctionne bien, avec PHP.
> 
> En python, la doc est dans le code, toujours, et accessible en cours de
> programmation pour quelqu'un qui programme dans une console python
> interactive. Pratique.

Oui oui. C'est le principe de doxygen, tu mets la doc dans le code, et
doxygen sait l'extraire pour faire des fichiers html/pdf/... si besoin.

> > Et il existe aussi des outils de tests unitaires, pour PHP. (je peux
> > pas comparer avec ceux pour Python, par contre, je ne connais pas
> > assez)
> 
> Je ne connais pas bien ceux de PHP non plus. Mais en python, l'outil
> le plus simple de test unitaire execute tous les exemple qui sont
> contenus dans la doc elle-meme incluse dans le code, par ces deux
> betes lignes:
>     import doctest
>     doctest.testmod()
> 
> Et je trouve que PHP perd de son sens (et de ses fonctionnalités)
> en-dehors d'un serveur web (d'ailleurs, PHP=PHP Hypertext
> Preprocessor, hein); ça ne simplifie pas le contrôle du code par un
> 'tit makefile.

Avec l'intepréteur PHP en CLI (qui est abondamment utilisé par AlternC
actuellement), tu peux faire tes tests avec un Makefile.

> >> * confort de codage avoir un accès interactif au code en cours est
> >> pour moi un *énorme* confort de développement)
> > 
> > Moui. Même si on parle de développement web, hein. (et je ne crois
> > pas qu'Eclipse/PHP soit encore suffisament avancé)
> 
> Bah alternd, le démon, non c'est pas du web. La classe "compte
> alternc", la classe "domaine", la classe "mailing-list", c'est pas du
> web; apres, la maniere d'afficher ça sur une page web dans un contexte
> html, c'est du detail si les objets sont accessibles de maniere simple
> et logique.

Moui, c'est vrai qu'alternd sort du modèle purement web.

> >> * extensions standard pour toutes les fonctionnalités imaginables
> >> en vrac et en masse, modules json, kid, markdown, crypto, ldap,
> >> pam, sqlite, sqlobject, xmlrpc, parsing, turbomail, rwhois, dns,
> >> ftp, curse, etc...
> > 
> > Bof. Tout ça, tu l'as dans PHP aussi.
> 
> J'ai toujours l'impression (difficile a expliquer, peut-etre partisane
> ou irrationnelle) que le faire en php, c'est infiniment plus
> douloureux, laborieux, sale, toussa.

Les égouts et les douleurs...

> >> * gestion naturelle de la notion de plugin
> > 
> > Tu peux expliciter ?
> 
> Oui. Modules, introspection et objet. Si on décide que tous les
> plugins sont des fichiers python dans un certain répertoire, il est
> très facile d'avoir le code qui va charger chacun de ces fichiers
> (chaque fichier étant un module python = un plugin, avec son propre
> namespace), puis lister les methodes disponibles. Si un standard
> alternC dit que les plugins fournissent
> * une methode foo pour l'affichage dans le menu du panel
> * une methode bar pour l'affichage en page principale du panel
> * une methode truc pour la commande xmlrpc
> * une methode bidule pour la reception de commande xmlrpc
> Bah... on a tout, non?

Et qu'est ce qu'on a, là, qu'on aurait pas avec PHP ?
(un fichier pour un plugin, un espace de nom séparé dans les classes,
...)

> Le code peut explorer le code (pas le code source, le code chargé,
> interprété), ça me semble un concept des plus utiles dans ce contexte.
> 
> >> * lisibilité, simplicité
> > 
> > Ca, c'est plus une question de celui qui se trouve derrière le
> > clavier, qu'une question d'outil.
> 
> Euh, je ne suis pas d'accord. Pourquoi y a-t'il des {, des }, des ;,
> des $, des " ou ' en php? Tout ça ne sert a rien si le parser est un
> peu intelligent, et python l'est. Du coup, c'est plus simple, plus
> facile à lire.

Pour _moi_ je trouve plus simple de lire un truc - correctement indenté
- qui délimite avec des {} les blocs, avec des $ les variables, ... que
du python. 
(je trouve le langage chouette, hein, mais n'avoir QUE l'indentation
pour donner l'imbrication, j'ai l'impression de refaire du COBOL...)

> J'ai du mal à l'expliquer de manière convaincante, mais j'ai
> l'impression que tout le code py que j'ai eu sous les yeux est
> toujours plus clair que le code php. Peut-être que le langage lui-même
> influe sur le style de celui qui code, je ne sais pas...

PHP est plus attrayant pour quelqu'un qui code comme un sagouin. De
fait, la proportion de code dégueu est importante.


Dom

-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
57, route de Paris 80000 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.fr



Plus d'informations sur la liste de diffusion Dev