Apres, il y a des gens qui ont reinvente une roue dont on dit pas mal de bien. http://www.iinteractive.com/moose/
Oui, pas mal effectivement...
Ca depend un peu a quel point tu veux tout faire a la main ou pas...
Mais ça a l'air un peu overkill pour mon projet...
Merci de l'info, je la garde sous le coude...
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Paul Gaborit
À (at) Tue, 28 Dec 2010 18:09:57 +0100, (Xavier) écrivait (wrote):
Marc Espie wrote:
Apres, il y a des gens qui ont reinvente une roue dont on dit pas mal de bien. http://www.iinteractive.com/moose/
Oui, pas mal effectivement...
Ca depend un peu a quel point tu veux tout faire a la main ou pas...
Mais ça a l'air un peu overkill pour mon projet...
Merci de l'info, je la garde sous le coude...
Perl ne propose (sans imposer) que les mécanismes de base pour faire ce qu'on veut ou presque en orienté objet.
Si on batit tout soi-même à partir de cela, on a l'intérêt de faire exactement ce qu'on veut au risque de ne pas le faire de manière toujours efficace mais en comprenant parfaitement ce qu'il y a derrière chaque mécanisme.
À l'inverse, en prenant un module comme Moose comme base de départ, il n'y a pas à tout (ré)écrire et donc on y gagne énormément en temps d'écriture mais le cadre est imposé et il faut l'adopter même si on ne comprend pas tout ce qu'il y a derrière.
Adopter le premier point de vue est intéressant pour apprendre Perl et pour de tous petits projets. Le second point de vue vise l'efficacité mais nécessite de choisir son ou ses modules de départ et de bien les connaître.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) Tue, 28 Dec 2010 18:09:57 +0100,
xavier@groumpf.org (Xavier) écrivait (wrote):
Marc Espie <espie@lain.home> wrote:
Apres, il y a des gens qui ont reinvente une roue dont on dit pas mal
de bien.
http://www.iinteractive.com/moose/
Oui, pas mal effectivement...
Ca depend un peu a quel point tu veux tout faire a la main ou pas...
Mais ça a l'air un peu overkill pour mon projet...
Merci de l'info, je la garde sous le coude...
Perl ne propose (sans imposer) que les mécanismes de base pour faire ce
qu'on veut ou presque en orienté objet.
Si on batit tout soi-même à partir de cela, on a l'intérêt de faire
exactement ce qu'on veut au risque de ne pas le faire de manière
toujours efficace mais en comprenant parfaitement ce qu'il y a derrière
chaque mécanisme.
À l'inverse, en prenant un module comme Moose comme base de départ, il
n'y a pas à tout (ré)écrire et donc on y gagne énormément en temps
d'écriture mais le cadre est imposé et il faut l'adopter même si on ne
comprend pas tout ce qu'il y a derrière.
Adopter le premier point de vue est intéressant pour apprendre Perl et
pour de tous petits projets. Le second point de vue vise l'efficacité
mais nécessite de choisir son ou ses modules de départ et de bien les
connaître.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) Tue, 28 Dec 2010 18:09:57 +0100, (Xavier) écrivait (wrote):
Marc Espie wrote:
Apres, il y a des gens qui ont reinvente une roue dont on dit pas mal de bien. http://www.iinteractive.com/moose/
Oui, pas mal effectivement...
Ca depend un peu a quel point tu veux tout faire a la main ou pas...
Mais ça a l'air un peu overkill pour mon projet...
Merci de l'info, je la garde sous le coude...
Perl ne propose (sans imposer) que les mécanismes de base pour faire ce qu'on veut ou presque en orienté objet.
Si on batit tout soi-même à partir de cela, on a l'intérêt de faire exactement ce qu'on veut au risque de ne pas le faire de manière toujours efficace mais en comprenant parfaitement ce qu'il y a derrière chaque mécanisme.
À l'inverse, en prenant un module comme Moose comme base de départ, il n'y a pas à tout (ré)écrire et donc on y gagne énormément en temps d'écriture mais le cadre est imposé et il faut l'adopter même si on ne comprend pas tout ce qu'il y a derrière.
Adopter le premier point de vue est intéressant pour apprendre Perl et pour de tous petits projets. Le second point de vue vise l'efficacité mais nécessite de choisir son ou ses modules de départ et de bien les connaître.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
xavier
Paul Gaborit wrote:
Adopter le premier point de vue est intéressant pour apprendre Perl et pour de tous petits projets. Le second point de vue vise l'efficacité mais nécessite de choisir son ou ses modules de départ et de bien les connaître.
Exactement comme à l'époque où je codais des applis en C++ : pour les gros projets, j'utilisais le framework de l'éditeur de mon IDE (Think Class Library, ça nous rajeunit pas :-) Pour les petits, j'utilisais mon framework maison qu'éviemment je connaissais mieux.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Adopter le premier point de vue est intéressant pour apprendre Perl et
pour de tous petits projets. Le second point de vue vise l'efficacité
mais nécessite de choisir son ou ses modules de départ et de bien les
connaître.
Exactement comme à l'époque où je codais des applis en C++ : pour les
gros projets, j'utilisais le framework de l'éditeur de mon IDE (Think
Class Library, ça nous rajeunit pas :-) Pour les petits, j'utilisais mon
framework maison qu'éviemment je connaissais mieux.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Adopter le premier point de vue est intéressant pour apprendre Perl et pour de tous petits projets. Le second point de vue vise l'efficacité mais nécessite de choisir son ou ses modules de départ et de bien les connaître.
Exactement comme à l'époque où je codais des applis en C++ : pour les gros projets, j'utilisais le framework de l'éditeur de mon IDE (Think Class Library, ça nous rajeunit pas :-) Pour les petits, j'utilisais mon framework maison qu'éviemment je connaissais mieux.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
espie
In article , Paul Gaborit <Paul.Gaborit+ wrote:
Si on batit tout soi-même à partir de cela, on a l'intérêt de faire exactement ce qu'on veut au risque de ne pas le faire de manière toujours efficace mais en comprenant parfaitement ce qu'il y a derrière chaque mécanisme.
À l'inverse, en prenant un module comme Moose comme base de départ, il n'y a pas à tout (ré)écrire et donc on y gagne énormément en temps d'écriture mais le cadre est imposé et il faut l'adopter même si on ne comprend pas tout ce qu'il y a derrière.
Adopter le premier point de vue est intéressant pour apprendre Perl et pour de tous petits projets. Le second point de vue vise l'efficacité mais nécessite de choisir son ou ses modules de départ et de bien les connaître.
Comme toujours en perl, il y a plus d'une facon de faire les choses.
L'existence de Moose, c'est juste une info interessante pour le debutant (en perl), histoire de savoir qu'il y a deja toute une culture (enfin, plusieurs) derriere la creation de code objet en perl.
J'aurais du aussi parler du pattern 'inside-out perl objects'.
Perso, je trouve que c'est une excellente chose que perl "de base" ne sache a peu pres rien faire cote objets et expose tous les mecanismes necessaires. C'est vraiment dans l'esprit de smalltalk, et ca a permis a des tonnes de gens de faire des choses tres sympathiques avec.
In article <wt9r5cz1u4a.fsf@enstimac.fr>,
Paul Gaborit <Paul.Gaborit+news@mines-albi.fr> wrote:
Si on batit tout soi-même à partir de cela, on a l'intérêt de faire
exactement ce qu'on veut au risque de ne pas le faire de manière
toujours efficace mais en comprenant parfaitement ce qu'il y a derrière
chaque mécanisme.
À l'inverse, en prenant un module comme Moose comme base de départ, il
n'y a pas à tout (ré)écrire et donc on y gagne énormément en temps
d'écriture mais le cadre est imposé et il faut l'adopter même si on ne
comprend pas tout ce qu'il y a derrière.
Adopter le premier point de vue est intéressant pour apprendre Perl et
pour de tous petits projets. Le second point de vue vise l'efficacité
mais nécessite de choisir son ou ses modules de départ et de bien les
connaître.
Comme toujours en perl, il y a plus d'une facon de faire les choses.
L'existence de Moose, c'est juste une info interessante pour le debutant (en
perl), histoire de savoir qu'il y a deja toute une culture (enfin, plusieurs)
derriere la creation de code objet en perl.
J'aurais du aussi parler du pattern 'inside-out perl objects'.
Perso, je trouve que c'est une excellente chose que perl "de base" ne
sache a peu pres rien faire cote objets et expose tous les mecanismes
necessaires. C'est vraiment dans l'esprit de smalltalk, et ca a permis a
des tonnes de gens de faire des choses tres sympathiques avec.
Si on batit tout soi-même à partir de cela, on a l'intérêt de faire exactement ce qu'on veut au risque de ne pas le faire de manière toujours efficace mais en comprenant parfaitement ce qu'il y a derrière chaque mécanisme.
À l'inverse, en prenant un module comme Moose comme base de départ, il n'y a pas à tout (ré)écrire et donc on y gagne énormément en temps d'écriture mais le cadre est imposé et il faut l'adopter même si on ne comprend pas tout ce qu'il y a derrière.
Adopter le premier point de vue est intéressant pour apprendre Perl et pour de tous petits projets. Le second point de vue vise l'efficacité mais nécessite de choisir son ou ses modules de départ et de bien les connaître.
Comme toujours en perl, il y a plus d'une facon de faire les choses.
L'existence de Moose, c'est juste une info interessante pour le debutant (en perl), histoire de savoir qu'il y a deja toute une culture (enfin, plusieurs) derriere la creation de code objet en perl.
J'aurais du aussi parler du pattern 'inside-out perl objects'.
Perso, je trouve que c'est une excellente chose que perl "de base" ne sache a peu pres rien faire cote objets et expose tous les mecanismes necessaires. C'est vraiment dans l'esprit de smalltalk, et ca a permis a des tonnes de gens de faire des choses tres sympathiques avec.
xavier
Marc Espie wrote:
J'aurais du aussi parler du pattern 'inside-out perl objects'.
Ah oui, tiens, cette approche est très intéressante...
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Marc Espie <espie@lain.home> wrote:
J'aurais du aussi parler du pattern 'inside-out perl objects'.
Ah oui, tiens, cette approche est très intéressante...
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Voici une doc sur Perl et la POO : http://djibril.developpez.com/tutoriels/perl/poo/
espie
In article , perlgenome wrote:
Voici une doc sur Perl et la POO : http://djibril.developpez.com/tutoriels/perl/poo/
Pas trop perl dans l'ame, cette introduction. Il y a pas mal de choses qui sont presentees comme "quasi-automatiques", alors qu'on a vachement le choix (le coup du ref($class) || $class, par exemple, c'est pas toujours approprie de pouvoir faire $object->new, vaut mieux meme se poser serieusement la question)
Et j'ai du mal a prendre au serieux un tuto qui parle tres tres vite d'heritage multiple, mais qui deconseille l'utilisation d'AUTOLOAD...
(alors que l'heritage multiple est tres souvent source d'emmerdes sans nom, et se remplace par plein d'autres mecanismes, et qu'AUTOLOAD est vachement utile pour implementer simplement plein de patterns. Tiens, au hasard, visitor, par exemple:
sub AUTOLOAD { our $AUTOLOAD; my $fullsub = $AUTOLOAD; (my $sub = $fullsub) =~ s/.*:://o; return if $sub eq 'DESTROY'; # special case my $self = $_[0]; # verify it makes sense if ($self->element_class->can($sub)) { no strict "refs"; # create the sub to avoid regenerating further calls *$fullsub = sub { my $self = shift; $self->visit($sub, @_); }; # and jump to it goto &$fullsub; } else { die "Can't call $sub on ".ref($self); } }
In article <75f93712-c768-4ed5-b69c-549c603f44f1@g26g2000vbz.googlegroups.com>,
perlgenome <genomart@gmail.com> wrote:
Voici une doc sur Perl et la POO :
http://djibril.developpez.com/tutoriels/perl/poo/
Pas trop perl dans l'ame, cette introduction. Il y a pas mal de choses
qui sont presentees comme "quasi-automatiques", alors qu'on a vachement le
choix (le coup du ref($class) || $class, par exemple, c'est pas toujours
approprie de pouvoir faire $object->new, vaut mieux meme se poser
serieusement la question)
Et j'ai du mal a prendre au serieux un tuto qui parle tres tres vite
d'heritage multiple, mais qui deconseille l'utilisation d'AUTOLOAD...
(alors que l'heritage multiple est tres souvent source d'emmerdes sans
nom, et se remplace par plein d'autres mecanismes, et qu'AUTOLOAD est
vachement utile pour implementer simplement plein de patterns. Tiens,
au hasard, visitor, par exemple:
sub AUTOLOAD
{
our $AUTOLOAD;
my $fullsub = $AUTOLOAD;
(my $sub = $fullsub) =~ s/.*:://o;
return if $sub eq 'DESTROY'; # special case
my $self = $_[0];
# verify it makes sense
if ($self->element_class->can($sub)) {
no strict "refs";
# create the sub to avoid regenerating further calls
*$fullsub = sub {
my $self = shift;
$self->visit($sub, @_);
};
# and jump to it
goto &$fullsub;
} else {
die "Can't call $sub on ".ref($self);
}
}
Voici une doc sur Perl et la POO : http://djibril.developpez.com/tutoriels/perl/poo/
Pas trop perl dans l'ame, cette introduction. Il y a pas mal de choses qui sont presentees comme "quasi-automatiques", alors qu'on a vachement le choix (le coup du ref($class) || $class, par exemple, c'est pas toujours approprie de pouvoir faire $object->new, vaut mieux meme se poser serieusement la question)
Et j'ai du mal a prendre au serieux un tuto qui parle tres tres vite d'heritage multiple, mais qui deconseille l'utilisation d'AUTOLOAD...
(alors que l'heritage multiple est tres souvent source d'emmerdes sans nom, et se remplace par plein d'autres mecanismes, et qu'AUTOLOAD est vachement utile pour implementer simplement plein de patterns. Tiens, au hasard, visitor, par exemple:
sub AUTOLOAD { our $AUTOLOAD; my $fullsub = $AUTOLOAD; (my $sub = $fullsub) =~ s/.*:://o; return if $sub eq 'DESTROY'; # special case my $self = $_[0]; # verify it makes sense if ($self->element_class->can($sub)) { no strict "refs"; # create the sub to avoid regenerating further calls *$fullsub = sub { my $self = shift; $self->visit($sub, @_); }; # and jump to it goto &$fullsub; } else { die "Can't call $sub on ".ref($self); } }
