GNT sans publicité, site mobile, fonctionnalitées exclusives...

Liste des instances d'une classe

Le
xavier
Bonjour,

Je ne suis pour l'instant qu'utilisateur de l'interface OOP de Perl,
mais le projet auquel je m'attaque va m'amener à créer ma ou mes propres
classes.

Comme ce sont des objets graphiques, je vais avoir besoin d'une méthode
"overlap" pour savoir s'il y a du monde là où je dessine.

En C++, je faisais ça simplement en créant un attribut de classe
(static) qui était au choix un tableau ou une liste chaînée des
instances.

Je ne voudrais pas avoir à réinventer la roue et savoir si un tel
mécanisme listant les instances d'une classe est déja présent dans Perl.

Merci,

--
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)
Lire les 10 réponses

Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Paul Gaborit
Le #22962481
À (at) Mon, 27 Dec 2010 19:54:17 +0100,
(Xavier) écrivait (wrote):

En C++, je faisais ça simplement en créant un attribut de classe
(static) qui était au choix un tableau ou une liste chaînée des
instances.

Je ne voudrais pas avoir à réinventer la roue et savoir si un tel
mécanisme listant les instances d'une classe est déja présent dans Perl.



Non, il n'y a rien de ce genre par défaut. Mais une variable gloable à
un package se comportera exactement comme un attribut de classe.

--
Paul Gaborit - Perl en français -
xavier
Le #22963311
Paul Gaborit
Non, il n'y a rien de ce genre par défaut. Mais une variable gloable à
un package se comportera exactement comme un attribut de classe.



OK, merci !

--
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
Le #22963551
In article Xavier
Bonjour,

Je ne suis pour l'instant qu'utilisateur de l'interface OOP de Perl,
mais le projet auquel je m'attaque va m'amener à créer ma ou mes propres
classes.

Comme ce sont des objets graphiques, je vais avoir besoin d'une méthode
"overlap" pour savoir s'il y a du monde là où je dessine.

En C++, je faisais ça simplement en créant un attribut de classe
(static) qui était au choix un tableau ou une liste chaînée des
instances.

Je ne voudrais pas avoir à réinventer la roue et savoir si un tel
mécanisme listant les instances d'une classe est déja présent dans Perl.



Apres, il y a des gens qui ont reinvente une roue dont on dit pas mal
de bien.
http://www.iinteractive.com/moose/

Ca depend un peu a quel point tu veux tout faire a la main ou pas...
xavier
Le #22964311
Marc Espie
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
Le #22969491
À (at) Tue, 28 Dec 2010 18:09:57 +0100,
(Xavier) écrivait (wrote):

Marc Espie
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 - Perl en français -
Publicité
Suivre les réponses
Poster une réponse
Anonyme