Je me présente, utilisateur Windows et développeur occasionnel en VB
pour le boulot, principalement pour réaliser des interfaces utilisateur
avec des systèmes dacquisition de mesures physiques ou des commandes de
machines. Pourquoi VB ? Pour rester dans la continuité de ce qui avait
déjà été réalisé auparavant, tout simplement, le choix ne s'est jamais posé.
Actuellement, je cherche à évoluer dans un autre langage et à essayer
dintégrer de plus en plus Linux, que se soit pour une utilisation
personnelle ou professionnelle.
Renseignements pris, Python me semble être un langage en vogue et promis
à un bel avenir !
Je nai malheureusement pas trouvé (je nai peut être pas bien cherché)
beaucoup dexemples dapplications écrites en Python. Pouvez-vous men
citer ?
Jaurais également désiré connaître votre profil de programmeur ? Doù
venez-vous, pourquoi et pour quelles tâches utilisez-vous Pyhton ?
Utilisez-vous un environnement de développement tel que Boa ?
On Thu, 22 Feb 2007 08:44:28 +0100, NicolasP wrote:
class Foo(object): def __init__(self, bar): self.bar = bar @apply def bar(): def fget(self): return self._bar * 2 def fset(self, bar): self._bar = bar return property(**locals())
Je ne suis pas un expert en Python et je ne comprends pas ce que fais cette classe. Bruno, pourrais tu m'expliquer ce que ça fait et comment on l'utilise ?
C'est un raccourci pour:
class Foo(object): def __init__(self, bar): self.bar = bar
def get_bar(self): return self._bar * 2 def set_bar(self, bar): self._bar = bar bar = property(get_bar, set_bar)
Ca permet de créer un propriété dans la classe, qui se manipule comme un attribut mais appelle des méthodes derrière: si x est une instance de Foo, faire "x.bar = ..." appellera en fait set_bar (ou fset dans l'exemple de Bruno) et lire la valeur de x.bar appellera get_bar (ou fget). Ca permet d'éviter de créer des accesseurs partout "à la Java" pour des fois qu'on ait besoin plus tard de transfomer un attribut "en dur" en attribut calculé. En Python, un attribut est un attribut; si il a besoin de devenir un attribut calculé plus tard, on le transformera en propriété. --python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Ok pour ce que ça fait. Dans ta classe, c'est clair. Mais dans la classe de Bruno, je ne comprends pas comment ça marche. Surtout le décorateur.
Nicolas
On Thu, 22 Feb 2007 08:44:28 +0100, NicolasP <nicolasp@aaton.com> wrote:
class Foo(object):
def __init__(self, bar):
self.bar = bar
@apply
def bar():
def fget(self):
return self._bar * 2
def fset(self, bar):
self._bar = bar
return property(**locals())
Je ne suis pas un expert en Python et je ne comprends pas ce que fais
cette classe.
Bruno, pourrais tu m'expliquer ce que ça fait et comment on l'utilise ?
C'est un raccourci pour:
class Foo(object):
def __init__(self, bar):
self.bar = bar
def get_bar(self):
return self._bar * 2
def set_bar(self, bar):
self._bar = bar
bar = property(get_bar, set_bar)
Ca permet de créer un propriété dans la classe, qui se manipule comme un
attribut mais appelle des méthodes derrière: si x est une instance de
Foo, faire "x.bar = ..." appellera en fait set_bar (ou fset dans
l'exemple de Bruno) et lire la valeur de x.bar appellera get_bar (ou
fget). Ca permet d'éviter de créer des accesseurs partout "à la Java"
pour des fois qu'on ait besoin plus tard de transfomer un attribut "en
dur" en attribut calculé. En Python, un attribut est un attribut; si il
a besoin de devenir un attribut calculé plus tard, on le transformera en
propriété.
--python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Ok pour ce que ça fait. Dans ta classe, c'est clair. Mais dans la classe de Bruno, je ne comprends pas comment ça marche. Surtout le décorateur.
On Thu, 22 Feb 2007 08:44:28 +0100, NicolasP wrote:
class Foo(object): def __init__(self, bar): self.bar = bar @apply def bar(): def fget(self): return self._bar * 2 def fset(self, bar): self._bar = bar return property(**locals())
Je ne suis pas un expert en Python et je ne comprends pas ce que fais cette classe. Bruno, pourrais tu m'expliquer ce que ça fait et comment on l'utilise ?
C'est un raccourci pour:
class Foo(object): def __init__(self, bar): self.bar = bar
def get_bar(self): return self._bar * 2 def set_bar(self, bar): self._bar = bar bar = property(get_bar, set_bar)
Ca permet de créer un propriété dans la classe, qui se manipule comme un attribut mais appelle des méthodes derrière: si x est une instance de Foo, faire "x.bar = ..." appellera en fait set_bar (ou fset dans l'exemple de Bruno) et lire la valeur de x.bar appellera get_bar (ou fget). Ca permet d'éviter de créer des accesseurs partout "à la Java" pour des fois qu'on ait besoin plus tard de transfomer un attribut "en dur" en attribut calculé. En Python, un attribut est un attribut; si il a besoin de devenir un attribut calculé plus tard, on le transformera en propriété. --python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Ok pour ce que ça fait. Dans ta classe, c'est clair. Mais dans la classe de Bruno, je ne comprends pas comment ça marche. Surtout le décorateur.
Nicolas
bruno.desthuilliers
On 22 fév, 12:06, NicolasP wrote:
On Thu, 22 Feb 2007 08:44:28 +0100, NicolasP wrote:
class Foo(object): def __init__(self, bar): self.bar = bar @apply def bar(): def fget(self): return self._bar * 2 def fset(self, bar): self._bar = bar return property(**locals())
Je ne suis pas un expert en Python et je ne comprends pas ce que fais cette classe. Bruno, pourrais tu m'expliquer ce que ça fait et comment on l'utilis e ?
C'est un raccourci pour:
class Foo(object): def __init__(self, bar): self.bar = bar
def get_bar(self): return self._bar * 2 def set_bar(self, bar): self._bar = bar bar = property(get_bar, set_bar)
Ca permet de créer un propriété dans la classe, qui se manipule c omme un attribut mais appelle des méthodes derrière: (snip)
Ok pour ce que ça fait. Dans ta classe, c'est clair. Mais dans la class e de Bruno, je ne comprends pas comment ça marche. Surtout le décorateu r.
C'est un hack pour éviter de polluer l'espace de nommage de la classe avec les accesseur des propriétés. apply(func, args, keywords) est une fonction dépréciée, je te laisse consulter la doc. En l'occurrence, elle se contente de retourner le résultat l'exécution de fonction qu'elle décore - et donc (c'est le fonctionnement des décorateurs) de remplacer la fonction truc() par le résultat de l'appel à truc(). or, truc() retourne un objet property. On remplace donc la fonction truc() par une property du même nom.
L'équivalent - sans décorateur - serait:
class Foo(object): def __init__(self, bar): self.bar = bar
On 22 fév, 12:06, NicolasP <nicol...@aaton.com> wrote:
On Thu, 22 Feb 2007 08:44:28 +0100, NicolasP <nicol...@aaton.com> wrote:
class Foo(object):
def __init__(self, bar):
self.bar = bar
@apply
def bar():
def fget(self):
return self._bar * 2
def fset(self, bar):
self._bar = bar
return property(**locals())
Je ne suis pas un expert en Python et je ne comprends pas ce que fais
cette classe.
Bruno, pourrais tu m'expliquer ce que ça fait et comment on l'utilis e ?
C'est un raccourci pour:
class Foo(object):
def __init__(self, bar):
self.bar = bar
def get_bar(self):
return self._bar * 2
def set_bar(self, bar):
self._bar = bar
bar = property(get_bar, set_bar)
Ca permet de créer un propriété dans la classe, qui se manipule c omme un
attribut mais appelle des méthodes derrière:
(snip)
Ok pour ce que ça fait. Dans ta classe, c'est clair. Mais dans la class e de Bruno, je ne comprends pas comment ça marche. Surtout le décorateu r.
C'est un hack pour éviter de polluer l'espace de nommage de la classe
avec les accesseur des propriétés. apply(func, args, keywords) est
une fonction dépréciée, je te laisse consulter la doc. En
l'occurrence, elle se contente de retourner le résultat l'exécution de
fonction qu'elle décore - et donc (c'est le fonctionnement des
décorateurs) de remplacer la fonction truc() par le résultat de
l'appel à truc(). or, truc() retourne un objet property. On remplace
donc la fonction truc() par une property du même nom.
L'équivalent - sans décorateur - serait:
class Foo(object):
def __init__(self, bar):
self.bar = bar
On Thu, 22 Feb 2007 08:44:28 +0100, NicolasP wrote:
class Foo(object): def __init__(self, bar): self.bar = bar @apply def bar(): def fget(self): return self._bar * 2 def fset(self, bar): self._bar = bar return property(**locals())
Je ne suis pas un expert en Python et je ne comprends pas ce que fais cette classe. Bruno, pourrais tu m'expliquer ce que ça fait et comment on l'utilis e ?
C'est un raccourci pour:
class Foo(object): def __init__(self, bar): self.bar = bar
def get_bar(self): return self._bar * 2 def set_bar(self, bar): self._bar = bar bar = property(get_bar, set_bar)
Ca permet de créer un propriété dans la classe, qui se manipule c omme un attribut mais appelle des méthodes derrière: (snip)
Ok pour ce que ça fait. Dans ta classe, c'est clair. Mais dans la class e de Bruno, je ne comprends pas comment ça marche. Surtout le décorateu r.
C'est un hack pour éviter de polluer l'espace de nommage de la classe avec les accesseur des propriétés. apply(func, args, keywords) est une fonction dépréciée, je te laisse consulter la doc. En l'occurrence, elle se contente de retourner le résultat l'exécution de fonction qu'elle décore - et donc (c'est le fonctionnement des décorateurs) de remplacer la fonction truc() par le résultat de l'appel à truc(). or, truc() retourne un objet property. On remplace donc la fonction truc() par une property du même nom.
L'équivalent - sans décorateur - serait:
class Foo(object): def __init__(self, bar): self.bar = bar
On Thu, 22 Feb 2007 08:44:28 +0100, NicolasP wrote:
class Foo(object): def __init__(self, bar): self.bar = bar @apply def bar(): def fget(self): return self._bar * 2 def fset(self, bar): self._bar = bar return property(**locals()) Je ne suis pas un expert en Python et je ne comprends pas ce que fais
cette classe. Bruno, pourrais tu m'expliquer ce que ça fait et comment on l'utilise ? C'est un raccourci pour:
class Foo(object): def __init__(self, bar): self.bar = bar def get_bar(self): return self._bar * 2 def set_bar(self, bar): self._bar = bar bar = property(get_bar, set_bar) Ca permet de créer un propriété dans la classe, qui se manipule comme un attribut mais appelle des méthodes derrière: (snip)
Ok pour ce que ça fait. Dans ta classe, c'est clair. Mais dans la classe de Bruno, je ne comprends pas comment ça marche. Surtout le décorateur.
C'est un hack pour éviter de polluer l'espace de nommage de la classe avec les accesseur des propriétés. apply(func, args, keywords) est une fonction dépréciée, je te laisse consulter la doc. En l'occurrence, elle se contente de retourner le résultat l'exécution de fonction qu'elle décore - et donc (c'est le fonctionnement des décorateurs) de remplacer la fonction truc() par le résultat de l'appel à truc(). or, truc() retourne un objet property. On remplace donc la fonction truc() par une property du même nom.
L'équivalent - sans décorateur - serait:
class Foo(object): def __init__(self, bar): self.bar = bar
On 22 fév, 12:06, NicolasP <nicol...@aaton.com> wrote:
On Thu, 22 Feb 2007 08:44:28 +0100, NicolasP <nicol...@aaton.com> wrote:
class Foo(object):
def __init__(self, bar):
self.bar = bar
@apply
def bar():
def fget(self):
return self._bar * 2
def fset(self, bar):
self._bar = bar
return property(**locals())
Je ne suis pas un expert en Python et je ne comprends pas ce que fais
cette classe.
Bruno, pourrais tu m'expliquer ce que ça fait et comment on l'utilise ?
C'est un raccourci pour:
class Foo(object):
def __init__(self, bar):
self.bar = bar
def get_bar(self):
return self._bar * 2
def set_bar(self, bar):
self._bar = bar
bar = property(get_bar, set_bar)
Ca permet de créer un propriété dans la classe, qui se manipule comme un
attribut mais appelle des méthodes derrière:
(snip)
Ok pour ce que ça fait. Dans ta classe, c'est clair. Mais dans la classe de Bruno, je ne comprends pas comment ça marche. Surtout le décorateur.
C'est un hack pour éviter de polluer l'espace de nommage de la classe
avec les accesseur des propriétés. apply(func, args, keywords) est
une fonction dépréciée, je te laisse consulter la doc. En
l'occurrence, elle se contente de retourner le résultat l'exécution de
fonction qu'elle décore - et donc (c'est le fonctionnement des
décorateurs) de remplacer la fonction truc() par le résultat de
l'appel à truc(). or, truc() retourne un objet property. On remplace
donc la fonction truc() par une property du même nom.
L'équivalent - sans décorateur - serait:
class Foo(object):
def __init__(self, bar):
self.bar = bar
On Thu, 22 Feb 2007 08:44:28 +0100, NicolasP wrote:
class Foo(object): def __init__(self, bar): self.bar = bar @apply def bar(): def fget(self): return self._bar * 2 def fset(self, bar): self._bar = bar return property(**locals()) Je ne suis pas un expert en Python et je ne comprends pas ce que fais
cette classe. Bruno, pourrais tu m'expliquer ce que ça fait et comment on l'utilise ? C'est un raccourci pour:
class Foo(object): def __init__(self, bar): self.bar = bar def get_bar(self): return self._bar * 2 def set_bar(self, bar): self._bar = bar bar = property(get_bar, set_bar) Ca permet de créer un propriété dans la classe, qui se manipule comme un attribut mais appelle des méthodes derrière: (snip)
Ok pour ce que ça fait. Dans ta classe, c'est clair. Mais dans la classe de Bruno, je ne comprends pas comment ça marche. Surtout le décorateur.
C'est un hack pour éviter de polluer l'espace de nommage de la classe avec les accesseur des propriétés. apply(func, args, keywords) est une fonction dépréciée, je te laisse consulter la doc. En l'occurrence, elle se contente de retourner le résultat l'exécution de fonction qu'elle décore - et donc (c'est le fonctionnement des décorateurs) de remplacer la fonction truc() par le résultat de l'appel à truc(). or, truc() retourne un objet property. On remplace donc la fonction truc() par une property du même nom.
L'équivalent - sans décorateur - serait:
class Foo(object): def __init__(self, bar): self.bar = bar
Et, ça sent pire, de jour en jour, vu que je reste enfermé dans mon système ;o)
-- @-salutations
Michel Claveau
Michel Claveau
Bonsoir !
SQLAlchemy, comme SQL-Objet, et d'autres, ne sont que du mapping légèrement revisité.
Je pense, comme Amaury, qu'il doit y avoir moyen d'aller beaucoup loin, conceptuellement, dans la reprise/remplacement de SQL ; notamment, en changeant l'ordre d'approche des champs/tables/jointures/vues/triggers.
Dommage que je n'ai pas asse'z de temps, car ça me plairait bien, d'explorer ce secteur.
-- @-salutations
Michel Claveau
Bonsoir !
SQLAlchemy, comme SQL-Objet, et d'autres, ne sont que du mapping
légèrement revisité.
Je pense, comme Amaury, qu'il doit y avoir moyen d'aller beaucoup loin,
conceptuellement, dans la reprise/remplacement de SQL ; notamment, en
changeant l'ordre d'approche des champs/tables/jointures/vues/triggers.
Dommage que je n'ai pas asse'z de temps, car ça me plairait bien,
d'explorer ce secteur.
SQLAlchemy, comme SQL-Objet, et d'autres, ne sont que du mapping légèrement revisité.
Je pense, comme Amaury, qu'il doit y avoir moyen d'aller beaucoup loin, conceptuellement, dans la reprise/remplacement de SQL ; notamment, en changeant l'ordre d'approche des champs/tables/jointures/vues/triggers.
Dommage que je n'ai pas asse'z de temps, car ça me plairait bien, d'explorer ce secteur.
-- @-salutations
Michel Claveau
Bruno Desthuilliers
Bonsoir !
SQLAlchemy, comme SQL-Objet, et d'autres, ne sont que du mapping légèrement revisité.
Michel, je ne suis pas sûr que tu ais vraiment utilisé SQLAlchemy. Avant d'être un ORM, c'est surtout - et essentiellement - une interface Python/SQL. On peut parfaitement utiliser SQLAlchemy sans la partie ORM.
Bonsoir !
SQLAlchemy, comme SQL-Objet, et d'autres, ne sont que du mapping
légèrement revisité.
Michel, je ne suis pas sûr que tu ais vraiment utilisé SQLAlchemy. Avant
d'être un ORM, c'est surtout - et essentiellement - une interface
Python/SQL. On peut parfaitement utiliser SQLAlchemy sans la partie ORM.
SQLAlchemy, comme SQL-Objet, et d'autres, ne sont que du mapping légèrement revisité.
Michel, je ne suis pas sûr que tu ais vraiment utilisé SQLAlchemy. Avant d'être un ORM, c'est surtout - et essentiellement - une interface Python/SQL. On peut parfaitement utiliser SQLAlchemy sans la partie ORM.
Michel, je ne suis pas sûr que tu ais vraiment utilisé SQLAlchemy
Effectivement, je n'ai regardé que de façon succincte.
Je jetterai donc un autre oeil dessus. Mais, ce sera pour plus tard, car, là, je suis occupé à explorer la voie BDE (Borland), ouverte par Jürgen Kareta (avec ctypes).
@-salutations
Michel Claveau
Salut !
Michel, je ne suis pas sûr que tu ais vraiment utilisé SQLAlchemy
Effectivement, je n'ai regardé que de façon succincte.
Je jetterai donc un autre oeil dessus.
Mais, ce sera pour plus tard, car, là, je suis occupé à explorer la voie BDE
(Borland), ouverte par Jürgen Kareta (avec ctypes).
Michel, je ne suis pas sûr que tu ais vraiment utilisé SQLAlchemy
Effectivement, je n'ai regardé que de façon succincte.
Je jetterai donc un autre oeil dessus. Mais, ce sera pour plus tard, car, là, je suis occupé à explorer la voie BDE (Borland), ouverte par Jürgen Kareta (avec ctypes).
@-salutations
Michel Claveau
Alex Marandon
Bruno Desthuilliers wrote:
Désolé, j'ai essayé plusieurs fois d'apprendre Perl, je n'ai jamais pu m'y faire. Idem en shell script et en PHP d'ailleurs.
Pour le PHP, je connais trop peu pour juger, mais ca pas l'air tres robuste, tant au niveau du langage que de l'interpreteur.
Pour Perl, c'est dommage, c'est un chouette langage, m'enfin on s'en passe tres bien quand on a Python.
Pour le shell tu dois quand meme bien etre capable d'en lire un peu non ? Ne serait-ce que pour jeter un oeil aux scripts de demarrages de ton OS.
C'est pareil en Perl. Les %, @ et $ renseignent juste sur une interface, tu implemente ce que tu veux en dessous ("perldoc perltie" pour en savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre personnel et totalement subjectif of course) que ça relève plus de brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si c'est Perl, c'est du brouillage d'information ;)
Oui : le protocole descripteur.
class Foo(object): def __init__(self, bar): self.bar = bar
Argh! Mais que sont ces '@' et '**', ciel, des caracteres non-alphanumeriques, mais c'est illisible !-)
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en Gougle Francais sur 'protocole descripteur' donne trois resultats qui sont des articles Usenet d'un certain Bruno Desthuilliers), c'etait assez stimulant intellectuellement, je suis pas sur d'avoir tout bien compris, m'enfin suffisament quand meme pour comprendre ton exemple. Enfin presque, je suis aussi alle me renseigner sur locals() et me rafraichir la memoire sur l'operateur **. Enfin, j'ai cherche en vain une reference sur @apply, j'ai pas trop insiste vu que je suis en mesure de comprendre la version sans decorateurs et que tu dis plus bas que c'est deprecié.
Donc voila, pfiou, tout ca pour ca. Et apres on va dire que Perl est obscur. Au final, je pense que je vais garder ma solution a base de __getattr__, nettement plus lisible, a mon tres subjectif avis.
Et avant que tu t'emballes, oui, j'ai bien compris que ca permettait pas que de changer des attributs en valeurs calculées, mais que ca permet aussi de faire des choses formidables comme des methodes statiques (whaou !) et des methodes de classes (dont je ne sais pas a quoi elle peuvent bien servir) et plein d'autres choses ésoteriques dont sont friands les obfuscateurs orientés objet pour rendre leur code incomprehensible au programmeur d'en bas.
Par contre Perl n'est encore une fois pas en reste sur ce point, le nom du constucteur est completement libre, j'ai choisi new() pour l'exemple. Du coup, pour peu que ta factory soit dans le meme package (ce qui ne veut pas dire dans le meme fichier), elle peut remplacer un constructeur sans que le code client soit au courant.
Pas compris...
Bon, j'essaye par l'example alors.
# Creation d'une instance de Aldo et assignation a une variable $objet my $objet = new Aldo;
# Definition de la classe Aldo package Aldo; sub new { return bless {}; }
Le jour ou je veux que new fasse autre que renvoyer une instance de Aldo, comme par example renvoyer des instances d'autres classes, je modifie le corps de new et je n'ai pas besoin de modifier le client.
# On modifie la definition de la classe Aldo package Aldo; sub new { if (...) { return new Bezu; } else { return new Sim; } }
Et voila :)
Bruno Desthuilliers wrote:
Désolé, j'ai essayé plusieurs fois d'apprendre Perl, je n'ai jamais pu
m'y faire. Idem en shell script et en PHP d'ailleurs.
Pour le PHP, je connais trop peu pour juger, mais ca pas l'air tres robuste,
tant au niveau du langage que de l'interpreteur.
Pour Perl, c'est dommage, c'est un chouette langage, m'enfin on s'en passe
tres bien quand on a Python.
Pour le shell tu dois quand meme bien etre capable d'en lire un peu non ? Ne
serait-ce que pour jeter un oeil aux scripts de demarrages de ton OS.
C'est pareil en Perl. Les %, @ et $ renseignent juste sur une interface,
tu implemente ce que tu veux en dessous ("perldoc perltie" pour en
savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre
personnel et totalement subjectif of course) que ça relève plus de
brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si
c'est Perl, c'est du brouillage d'information ;)
Oui : le protocole descripteur.
class Foo(object):
def __init__(self, bar):
self.bar = bar
Argh! Mais que sont ces '@' et '**', ciel, des caracteres
non-alphanumeriques, mais c'est illisible !-)
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en Gougle
Francais sur 'protocole descripteur' donne trois resultats qui sont des
articles Usenet d'un certain Bruno Desthuilliers), c'etait assez stimulant
intellectuellement, je suis pas sur d'avoir tout bien compris, m'enfin
suffisament quand meme pour comprendre ton exemple. Enfin presque, je suis
aussi alle me renseigner sur locals() et me rafraichir la memoire sur
l'operateur **. Enfin, j'ai cherche en vain une reference sur @apply, j'ai
pas trop insiste vu que je suis en mesure de comprendre la version sans
decorateurs et que tu dis plus bas que c'est deprecié.
Donc voila, pfiou, tout ca pour ca. Et apres on va dire que Perl est obscur.
Au final, je pense que je vais garder ma solution a base de __getattr__,
nettement plus lisible, a mon tres subjectif avis.
Et avant que tu t'emballes, oui, j'ai bien compris que ca permettait pas que
de changer des attributs en valeurs calculées, mais que ca permet aussi de
faire des choses formidables comme des methodes statiques (whaou !) et des
methodes de classes (dont je ne sais pas a quoi elle peuvent bien servir)
et plein d'autres choses ésoteriques dont sont friands les obfuscateurs
orientés objet pour rendre leur code incomprehensible au programmeur d'en
bas.
Par contre Perl n'est encore une fois pas en reste sur ce point, le nom
du constucteur est completement libre, j'ai choisi new() pour l'exemple.
Du coup, pour peu que ta factory soit dans le meme package (ce qui ne
veut pas dire dans le meme fichier), elle peut remplacer un constructeur
sans que le code client soit au courant.
Pas compris...
Bon, j'essaye par l'example alors.
# Creation d'une instance de Aldo et assignation a une variable $objet
my $objet = new Aldo;
# Definition de la classe Aldo
package Aldo;
sub new { return bless {}; }
Le jour ou je veux que new fasse autre que renvoyer une instance de Aldo,
comme par example renvoyer des instances d'autres classes, je modifie le
corps de new et je n'ai pas besoin de modifier le client.
# On modifie la definition de la classe Aldo
package Aldo;
sub new {
if (...) {
return new Bezu;
} else {
return new Sim;
}
}
Désolé, j'ai essayé plusieurs fois d'apprendre Perl, je n'ai jamais pu m'y faire. Idem en shell script et en PHP d'ailleurs.
Pour le PHP, je connais trop peu pour juger, mais ca pas l'air tres robuste, tant au niveau du langage que de l'interpreteur.
Pour Perl, c'est dommage, c'est un chouette langage, m'enfin on s'en passe tres bien quand on a Python.
Pour le shell tu dois quand meme bien etre capable d'en lire un peu non ? Ne serait-ce que pour jeter un oeil aux scripts de demarrages de ton OS.
C'est pareil en Perl. Les %, @ et $ renseignent juste sur une interface, tu implemente ce que tu veux en dessous ("perldoc perltie" pour en savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre personnel et totalement subjectif of course) que ça relève plus de brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si c'est Perl, c'est du brouillage d'information ;)
Oui : le protocole descripteur.
class Foo(object): def __init__(self, bar): self.bar = bar
Argh! Mais que sont ces '@' et '**', ciel, des caracteres non-alphanumeriques, mais c'est illisible !-)
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en Gougle Francais sur 'protocole descripteur' donne trois resultats qui sont des articles Usenet d'un certain Bruno Desthuilliers), c'etait assez stimulant intellectuellement, je suis pas sur d'avoir tout bien compris, m'enfin suffisament quand meme pour comprendre ton exemple. Enfin presque, je suis aussi alle me renseigner sur locals() et me rafraichir la memoire sur l'operateur **. Enfin, j'ai cherche en vain une reference sur @apply, j'ai pas trop insiste vu que je suis en mesure de comprendre la version sans decorateurs et que tu dis plus bas que c'est deprecié.
Donc voila, pfiou, tout ca pour ca. Et apres on va dire que Perl est obscur. Au final, je pense que je vais garder ma solution a base de __getattr__, nettement plus lisible, a mon tres subjectif avis.
Et avant que tu t'emballes, oui, j'ai bien compris que ca permettait pas que de changer des attributs en valeurs calculées, mais que ca permet aussi de faire des choses formidables comme des methodes statiques (whaou !) et des methodes de classes (dont je ne sais pas a quoi elle peuvent bien servir) et plein d'autres choses ésoteriques dont sont friands les obfuscateurs orientés objet pour rendre leur code incomprehensible au programmeur d'en bas.
Par contre Perl n'est encore une fois pas en reste sur ce point, le nom du constucteur est completement libre, j'ai choisi new() pour l'exemple. Du coup, pour peu que ta factory soit dans le meme package (ce qui ne veut pas dire dans le meme fichier), elle peut remplacer un constructeur sans que le code client soit au courant.
Pas compris...
Bon, j'essaye par l'example alors.
# Creation d'une instance de Aldo et assignation a une variable $objet my $objet = new Aldo;
# Definition de la classe Aldo package Aldo; sub new { return bless {}; }
Le jour ou je veux que new fasse autre que renvoyer une instance de Aldo, comme par example renvoyer des instances d'autres classes, je modifie le corps de new et je n'ai pas besoin de modifier le client.
# On modifie la definition de la classe Aldo package Aldo; sub new { if (...) { return new Bezu; } else { return new Sim; } }
