Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Bonjour !
Un consensus semble se faire, autour de la proposition de syntaxe J2. Plus
de détails ici :
http://www.aminus.org/rbre/python/pydec.html
Qu'est-ce que la notion de Decorator ? Je n'ai pas bien vu toute la
subtilité de la chose, mais voici ce qu'il me semble être le plus
compréhensible :
Les decorateurs ajoutent des "choses" aux méthodes ou fonctions, au moment
de leur création (à l'exécution du programme). Les "choses" ajoutées peuvent
de deux types :
- des attributs, qui ne modifient pas les classes/méthodes ; par
exemple l'auteur, ou la version ;
- des "meta-fonctions" qui s'appliquent lors de la création de
l'objet.
Les attributs ajoutent des facilités d'introspection, notamment aux
fonctions ; pour les classes, on pouvait déjà utiliser des attributs de
classes, ou des méthodes de classe et des méthodes statiques (à ne pas
confondre avec les méthodes d'instances).
Les "meta-fonctions" fonctionnent comme suit : soit le decorateur MAJ,
défini par ailleurs, et utilisé sur la fonction FONC. Lors de l'exécution du
programme, on aura, pour la création de FONC :
FONC = MAJ(FONC)
Si jamais j'ai mal compris, prière de me le signaler.
"Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle." writes:
Bonsoir !
Meles : La liste en intention est plus rapide. Mais ce n'est pas l'objet de ce débat.
Wilk : si tu veux gagner (un peu) des lignes, il est possible d'écrire :
a=[] for b in 'AZERTY': a.append(b) print a
En gardant une excellente lisibilité.
Tu trouves ?!
Et puis, si l'on cherche des programmes ultra-court, autant passer à Perl, ou Ocaml (ou Haskell). Mais alors, la lisibilité semble inversement proportionnelle au nombre de lignes.
Je ne cherche pas à avoir des programmes les plus courts possibles à tout prix, au contraire, je ne racourcis mes programmes que quand je vais y gagner en lisibilité, c'est totalement différent.
Par exemple, je n'utilise pas les listes en intention si elles doivent se retrouver sur plusieurs lignes.
La lisibilité n'est pas inversement proportionnelle au nombre de lignes, un exemple frapant est la méthode pour lire un fichier en java et en python (facteur 10)... Donc, dans certains cas moins il y a de lignes et mieux on se porte, tant qu'on ne tombe pas dans l'extrème inverse... C'est une histoire de compromis. Et du fait qu'on gagne en nombre de ligne, on hésite moins à utiliser des variables plus explicites (au lieu de i,j,k...), pour notre exemple, le 1) permet d'éviter l'utilisation d'une variable "jetable".
Ceci dit, si le chef avait décidé que ces listes perturbent trop de monde je m'en serai passé sans insister.
-- Wilk - http://flibuste.net
"Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle." <unseulmcmcmcmc@msupprimerlepoint.claveauPOINTcom> writes:
Bonsoir !
Meles : La liste en intention est plus rapide. Mais ce n'est pas l'objet de
ce débat.
Wilk : si tu veux gagner (un peu) des lignes, il est possible d'écrire :
a=[]
for b in 'AZERTY': a.append(b)
print a
En gardant une excellente lisibilité.
Tu trouves ?!
Et puis, si l'on cherche des programmes ultra-court, autant passer à Perl,
ou Ocaml (ou Haskell). Mais alors, la lisibilité semble inversement
proportionnelle au nombre de lignes.
Je ne cherche pas à avoir des programmes les plus courts possibles à
tout prix, au contraire, je ne racourcis mes programmes que quand je
vais y gagner en lisibilité, c'est totalement différent.
Par exemple, je n'utilise pas les listes en intention si elles doivent
se retrouver sur plusieurs lignes.
La lisibilité n'est pas inversement proportionnelle au nombre de lignes,
un exemple frapant est la méthode pour lire un fichier en java et en
python (facteur 10)... Donc, dans certains cas moins il y a de
lignes et mieux on se porte, tant qu'on ne tombe pas dans l'extrème
inverse... C'est une histoire de compromis.
Et du fait qu'on gagne en nombre de ligne, on hésite moins à utiliser
des variables plus explicites (au lieu de i,j,k...), pour notre exemple,
le 1) permet d'éviter l'utilisation d'une variable "jetable".
Ceci dit, si le chef avait décidé que ces listes perturbent trop de
monde je m'en serai passé sans insister.
"Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle." writes:
Bonsoir !
Meles : La liste en intention est plus rapide. Mais ce n'est pas l'objet de ce débat.
Wilk : si tu veux gagner (un peu) des lignes, il est possible d'écrire :
a=[] for b in 'AZERTY': a.append(b) print a
En gardant une excellente lisibilité.
Tu trouves ?!
Et puis, si l'on cherche des programmes ultra-court, autant passer à Perl, ou Ocaml (ou Haskell). Mais alors, la lisibilité semble inversement proportionnelle au nombre de lignes.
Je ne cherche pas à avoir des programmes les plus courts possibles à tout prix, au contraire, je ne racourcis mes programmes que quand je vais y gagner en lisibilité, c'est totalement différent.
Par exemple, je n'utilise pas les listes en intention si elles doivent se retrouver sur plusieurs lignes.
La lisibilité n'est pas inversement proportionnelle au nombre de lignes, un exemple frapant est la méthode pour lire un fichier en java et en python (facteur 10)... Donc, dans certains cas moins il y a de lignes et mieux on se porte, tant qu'on ne tombe pas dans l'extrème inverse... C'est une histoire de compromis. Et du fait qu'on gagne en nombre de ligne, on hésite moins à utiliser des variables plus explicites (au lieu de i,j,k...), pour notre exemple, le 1) permet d'éviter l'utilisation d'une variable "jetable".
Ceci dit, si le chef avait décidé que ces listes perturbent trop de monde je m'en serai passé sans insister.
-- Wilk - http://flibuste.net
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Bonsoir !
A la réflexion, je me range à ton argument, antérieur de quelques messages : puisque les anciennes syntaxes continuent d'exister, autant avoir une possibilité de plus. D'autant plus que rien n'oblige à l'utiliser.
Bonsoir !
A la réflexion, je me range à ton argument, antérieur de quelques messages :
puisque les anciennes syntaxes continuent d'exister, autant avoir une
possibilité de plus. D'autant plus que rien n'oblige à l'utiliser.
A la réflexion, je me range à ton argument, antérieur de quelques messages : puisque les anciennes syntaxes continuent d'exister, autant avoir une possibilité de plus. D'autant plus que rien n'oblige à l'utiliser.
