À (at) Wed, 13 Jun 2007 10:15:48 +0200, écrivait (wrote):
Bonjour à tous,
J'ai fait le programme suivant:
my @arr = qw(a b c); print $arr[0];
Jusque là, tout va bien (normal). Mais j'aimerais placer le nom du tabl eau dans une variable:
my $name = "arr";
et accéder au contenu du tableau en me servant de la variable... Et l à, je bloque:
no strict "refs"; print ${"$name"}[0];
ne marche pas comme je le voudrais.
Les références par nom sont déconseillées pour plein de bonnes raisons. La principale étant qu'elles ne sont (quasiment) jamais nécessaires.
Ceci étant, si on les autorise, elles ne fonctionnent que sur les variables globales et non sur les variables lexicales.
# my @arr = qw(a b c); our @arr = qw(a b c); print $arr[0]; my $name = "arr"; no strict "refs"; print ${"$name"}[0];
Là, ça marche car @arr n'est pas lexical.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
mzi
Paul Gaborit wrote:
Les références par nom sont déconseillées pour plein de bonnes raisons. La principale étant qu'elles ne sont (quasiment) jamais nécessaires.
Je pense que j'ai une bonne raison. Je veux créer des méthodes à la volée en fonction des champs (fields) d'un objet utilisant Object::InsideOut. Les méthodes créées à la volée doivent accéder aux champs (qui sont des tableaux).
Ceci étant, si on les autorise, elles ne fonctionnent que sur les variables globales et non sur les variables lexicales.
Merci.
Je ne suis pas certain de bien comprendre les implications de l'emploi de "our" plutôt que "my". Je ne vais pas casser toute la hiérarchie des paquetages si chacune de mes classes et ses sous classes ont des champs déclarés avec "our"?
Merci d'avance pour tout complément d'information.
-- mzi
Paul Gaborit wrote:
Les références par nom sont déconseillées pour plein de bonnes
raisons. La principale étant qu'elles ne sont (quasiment) jamais
nécessaires.
Je pense que j'ai une bonne raison. Je veux créer des méthodes à la volée en
fonction des champs (fields) d'un objet utilisant Object::InsideOut. Les
méthodes créées à la volée doivent accéder aux champs (qui sont des
tableaux).
Ceci étant, si on les autorise, elles ne fonctionnent que sur les
variables globales et non sur les variables lexicales.
Merci.
Je ne suis pas certain de bien comprendre les implications de l'emploi
de "our" plutôt que "my". Je ne vais pas casser toute la hiérarchie des
paquetages si chacune de mes classes et ses sous classes ont des champs
déclarés avec "our"?
Merci d'avance pour tout complément d'information.
Les références par nom sont déconseillées pour plein de bonnes raisons. La principale étant qu'elles ne sont (quasiment) jamais nécessaires.
Je pense que j'ai une bonne raison. Je veux créer des méthodes à la volée en fonction des champs (fields) d'un objet utilisant Object::InsideOut. Les méthodes créées à la volée doivent accéder aux champs (qui sont des tableaux).
Ceci étant, si on les autorise, elles ne fonctionnent que sur les variables globales et non sur les variables lexicales.
Merci.
Je ne suis pas certain de bien comprendre les implications de l'emploi de "our" plutôt que "my". Je ne vais pas casser toute la hiérarchie des paquetages si chacune de mes classes et ses sous classes ont des champs déclarés avec "our"?
Merci d'avance pour tout complément d'information.
-- mzi
mzi
Ceci étant, si on les autorise, elles ne fonctionnent que sur les variables globales et non sur les variables lexicales.
Et le pire, c'est que la méthode que j'emploie (Object::InsideOut::create_field) génère une variable lexicale...
Je vais réfléchir à tout ça.
-- mzi
Ceci étant, si on les autorise, elles ne fonctionnent que sur les
variables globales et non sur les variables lexicales.
Et le pire, c'est que la méthode que j'emploie
(Object::InsideOut::create_field) génère une variable lexicale...
Ceci étant, si on les autorise, elles ne fonctionnent que sur les variables globales et non sur les variables lexicales.
Et le pire, c'est que la méthode que j'emploie (Object::InsideOut::create_field) génère une variable lexicale...
Je vais réfléchir à tout ça.
-- mzi
Paul Gaborit
À (at) Wed, 13 Jun 2007 13:48:26 +0200, écrivait (wrote):
Paul Gaborit wrote:
Les références par nom sont déconseillées pour plein de bonnes raisons. La principale étant qu'elles ne sont (quasiment) jamais nécessaires.
Je pense que j'ai une bonne raison. Je veux créer des méthodes à la volée en fonction des champs (fields) d'un objet utilisant Object::InsideOut. Les méthodes créées à la volée doivent accéder aux champs (qui so nt des tableaux).
Cette situation est tout à fait gérable sans utilisation des références par nom.
De toutes manières, dès que l'on fait de l'objet, on n'utilise quasiment jamais les variables globales. Il n'y a donc pas de références par nom à utiliser.
Je ne suis pas certain de bien comprendre les implications de l'emploi de "our" plutôt que "my". Je ne vais pas casser toute la hiérarchie d es paquetages si chacune de mes classes et ses sous classes ont des champs déclarés avec "our"?
Vos champs sont globaux à toute une classe (ce sont les mêmes pour tous les objets de la classe) ? Si c'est cela alors on peut effectivement utiliser une variable globale (au paquetage) pour chacun de ces champs.
On peut aussi utiliser une seule variable globale. Par exemple, une table de hachage avec une clé par champ (comme ça, on peut créer ou supprimer des champs dynamiquement et ne pas utiliser de références globales).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 13 Jun 2007 13:48:26 +0200,
mzi@gmail.com écrivait (wrote):
Paul Gaborit wrote:
Les références par nom sont déconseillées pour plein de bonnes
raisons. La principale étant qu'elles ne sont (quasiment) jamais
nécessaires.
Je pense que j'ai une bonne raison. Je veux créer des méthodes à la volée en
fonction des champs (fields) d'un objet utilisant Object::InsideOut. Les
méthodes créées à la volée doivent accéder aux champs (qui so nt des
tableaux).
Cette situation est tout à fait gérable sans utilisation des
références par nom.
De toutes manières, dès que l'on fait de l'objet, on n'utilise
quasiment jamais les variables globales. Il n'y a donc pas de
références par nom à utiliser.
Je ne suis pas certain de bien comprendre les implications de l'emploi
de "our" plutôt que "my". Je ne vais pas casser toute la hiérarchie d es
paquetages si chacune de mes classes et ses sous classes ont des champs
déclarés avec "our"?
Vos champs sont globaux à toute une classe (ce sont les mêmes pour
tous les objets de la classe) ? Si c'est cela alors on peut
effectivement utiliser une variable globale (au paquetage) pour chacun
de ces champs.
On peut aussi utiliser une seule variable globale. Par exemple, une
table de hachage avec une clé par champ (comme ça, on peut créer ou
supprimer des champs dynamiquement et ne pas utiliser de références
globales).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 13 Jun 2007 13:48:26 +0200, écrivait (wrote):
Paul Gaborit wrote:
Les références par nom sont déconseillées pour plein de bonnes raisons. La principale étant qu'elles ne sont (quasiment) jamais nécessaires.
Je pense que j'ai une bonne raison. Je veux créer des méthodes à la volée en fonction des champs (fields) d'un objet utilisant Object::InsideOut. Les méthodes créées à la volée doivent accéder aux champs (qui so nt des tableaux).
Cette situation est tout à fait gérable sans utilisation des références par nom.
De toutes manières, dès que l'on fait de l'objet, on n'utilise quasiment jamais les variables globales. Il n'y a donc pas de références par nom à utiliser.
Je ne suis pas certain de bien comprendre les implications de l'emploi de "our" plutôt que "my". Je ne vais pas casser toute la hiérarchie d es paquetages si chacune de mes classes et ses sous classes ont des champs déclarés avec "our"?
Vos champs sont globaux à toute une classe (ce sont les mêmes pour tous les objets de la classe) ? Si c'est cela alors on peut effectivement utiliser une variable globale (au paquetage) pour chacun de ces champs.
On peut aussi utiliser une seule variable globale. Par exemple, une table de hachage avec une clé par champ (comme ça, on peut créer ou supprimer des champs dynamiquement et ne pas utiliser de références globales).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
mzi
Paul Gaborit wrote:
Je veux créer des méthodes à la volée en fonction des champs (fields) d'un objet utilisant Object::InsideOut. Les méthodes créées à la volée doivent accéder aux champs (qui sont des tableaux).
Cette situation est tout à fait gérable sans utilisation des références par nom.
Effectivement... je viens de trouver un moyen qui paraît adéquat pour mon problème particulier, mais je ne suis pas certain que ce soit le plus performant.
Merci pour les clarifications sur les variables globales.
-- mzi
Paul Gaborit wrote:
Je veux créer des méthodes à la volée
en fonction des champs (fields) d'un objet utilisant Object::InsideOut.
Les méthodes créées à la volée doivent accéder aux champs (qui sont des
tableaux).
Cette situation est tout à fait gérable sans utilisation des
références par nom.
Effectivement... je viens de trouver un moyen qui paraît adéquat pour mon
problème particulier, mais je ne suis pas certain que ce soit le plus
performant.
Merci pour les clarifications sur les variables globales.
Je veux créer des méthodes à la volée en fonction des champs (fields) d'un objet utilisant Object::InsideOut. Les méthodes créées à la volée doivent accéder aux champs (qui sont des tableaux).
Cette situation est tout à fait gérable sans utilisation des références par nom.
Effectivement... je viens de trouver un moyen qui paraît adéquat pour mon problème particulier, mais je ne suis pas certain que ce soit le plus performant.
Merci pour les clarifications sur les variables globales.
-- mzi
Paul Gaborit
À (at) Wed, 13 Jun 2007 13:58:11 +0200, écrivait (wrote):
Ceci étant, si on les autorise, elles ne fonctionnent que sur les variables globales et non sur les variables lexicales.
Et le pire, c'est que la méthode que j'emploie (Object::InsideOut::create_field) génère une variable lexicale...
Peu importe la manière dont Object::InsideOut crée les champs. De toutes manières, sauf manipulation très particulière, vous ne devriez jamais y accèder par leur nom (à supposer qu'ils en aient un) mais par un accesseur (qui porte habituellement le nom du champ). Et là, comme c'est une méthode, on peut très bien utiliser le contenu d'une variable comme nom de méthode (sans passer outre les limitations de 'use strict').
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 13 Jun 2007 13:58:11 +0200,
mzi@gmail.com écrivait (wrote):
Ceci étant, si on les autorise, elles ne fonctionnent que sur les
variables globales et non sur les variables lexicales.
Et le pire, c'est que la méthode que j'emploie
(Object::InsideOut::create_field) génère une variable lexicale...
Peu importe la manière dont Object::InsideOut crée les champs. De
toutes manières, sauf manipulation très particulière, vous ne devriez
jamais y accèder par leur nom (à supposer qu'ils en aient un) mais par
un accesseur (qui porte habituellement le nom du champ). Et là, comme
c'est une méthode, on peut très bien utiliser le contenu d'une
variable comme nom de méthode (sans passer outre les limitations de
'use strict').
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 13 Jun 2007 13:58:11 +0200, écrivait (wrote):
Ceci étant, si on les autorise, elles ne fonctionnent que sur les variables globales et non sur les variables lexicales.
Et le pire, c'est que la méthode que j'emploie (Object::InsideOut::create_field) génère une variable lexicale...
Peu importe la manière dont Object::InsideOut crée les champs. De toutes manières, sauf manipulation très particulière, vous ne devriez jamais y accèder par leur nom (à supposer qu'ils en aient un) mais par un accesseur (qui porte habituellement le nom du champ). Et là, comme c'est une méthode, on peut très bien utiliser le contenu d'une variable comme nom de méthode (sans passer outre les limitations de 'use strict').
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Paul Gaborit
À (at) Wed, 13 Jun 2007 15:29:06 +0200, écrivait (wrote):
Effectivement... je viens de trouver un moyen qui paraît adéquat pour mon problème particulier, mais je ne suis pas certain que ce soit le plus performant.
Heu... Mieux vaut un programme qui donne la solution lentement qu'un programme qui plante rapidement. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 13 Jun 2007 15:29:06 +0200,
mzi@gmail.com écrivait (wrote):
Effectivement... je viens de trouver un moyen qui paraît adéquat pour mon
problème particulier, mais je ne suis pas certain que ce soit le plus
performant.
Heu... Mieux vaut un programme qui donne la solution lentement qu'un
programme qui plante rapidement. ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 13 Jun 2007 15:29:06 +0200, écrivait (wrote):
Effectivement... je viens de trouver un moyen qui paraît adéquat pour mon problème particulier, mais je ne suis pas certain que ce soit le plus performant.
Heu... Mieux vaut un programme qui donne la solution lentement qu'un programme qui plante rapidement. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
mzi
Paul Gaborit wrote:
Peu importe la manière dont Object::InsideOut crée les champs. De toutes manières, sauf manipulation très particulière, vous ne devriez jamais y accèder par leur nom (à supposer qu'ils en aient un) mais par un accesseur
En fait, les méthodes générées sont des accesseurs particuliers.
-- mzi
Paul Gaborit wrote:
Peu importe la manière dont Object::InsideOut crée les champs. De
toutes manières, sauf manipulation très particulière, vous ne devriez
jamais y accèder par leur nom (à supposer qu'ils en aient un) mais par
un accesseur
En fait, les méthodes générées sont des accesseurs particuliers.
Peu importe la manière dont Object::InsideOut crée les champs. De toutes manières, sauf manipulation très particulière, vous ne devriez jamais y accèder par leur nom (à supposer qu'ils en aient un) mais par un accesseur
En fait, les méthodes générées sont des accesseurs particuliers.
