question plus méthodologique que technique cette fois.
Continuant ma découverte des structures de données non-triviales en Perl, je
me rends compte qu'à l'usage ça me manque vachement l'équivalent d'un
fichier .h en C où il y aurait (entre autres) toutes les définitions (avec
typedef) des structures de données utilisées.
J'ai l'impression qu'en Perl les structures de données sont construites à la
volée et que donc la définition des structures est éparpillée dans le code
lui-même et du coup plus tard quand j'utilise les données je me souviens
pas toujours comment elles étaient structurée alors que si j'avais une
bonne vieille définition de type sous les yeux, ça irait mieux.
Voyez-vous ce que je veux dire ? Si oui, comment gérez-vous ça ?
Continuant ma découverte des structures de données non-triviales en Perl, je me rends compte qu'à l'usage ça me manque vachement l'équivalent d'un fichier .h en C où il y aurait (entre autres) toutes les définitions (avec typedef) des structures de données utilisées.
Les fichiers .h du C n'existent que pour des raisons techniques d'implémentation. Dans le cas des structures de données, ça permet au compilateur de connaître l'organisation et le type de chacun des éléments d'une structure.
L'aspect documentaire n'est qu'un effet secondaire involontaire.
J'ai l'impression qu'en Perl les structures de données sont construites à la volée et que donc la définition des structures est éparpillée dans le code lui-même et du coup plus tard quand j'utilise les données je me souviens pas toujours comment elles étaient structurée alors que si j'avais une bonne vieille définition de type sous les yeux, ça irait mieux.
Voyez-vous ce que je veux dire ? Si oui, comment gérez-vous ça ?
Comme toujours en Perl, il n'y a pas de méthodes générales pour gérer cela.
On peut faire "au vol" comme tu dis en utilisant quelques conventions de nommage des champs dans les tables de hachage pour faciliter les choses. Ou alors utiliser les nombreux modules permettant de créer et gérer des classes.
Il faut bien voir que, contrairement au C (et à plein d'autres langages), Perl est un langage dynamique. On peut quasiment tout changer au vol : même un objet (en fait une référence bénie) peut changer de classe (à ma connaissance, c'est le seul langage qui le permette). La notion de structure de données est quelque chose de trop figée. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Continuant ma découverte des structures de données non-triviales en Perl, je
me rends compte qu'à l'usage ça me manque vachement l'équivalent d'un
fichier .h en C où il y aurait (entre autres) toutes les définitions (avec
typedef) des structures de données utilisées.
Les fichiers .h du C n'existent que pour des raisons techniques
d'implémentation. Dans le cas des structures de données, ça permet au
compilateur de connaître l'organisation et le type de chacun des
éléments d'une structure.
L'aspect documentaire n'est qu'un effet secondaire involontaire.
J'ai l'impression qu'en Perl les structures de données sont construites à la
volée et que donc la définition des structures est éparpillée dans le code
lui-même et du coup plus tard quand j'utilise les données je me souviens
pas toujours comment elles étaient structurée alors que si j'avais une
bonne vieille définition de type sous les yeux, ça irait mieux.
Voyez-vous ce que je veux dire ? Si oui, comment gérez-vous ça ?
Comme toujours en Perl, il n'y a pas de méthodes générales pour gérer
cela.
On peut faire "au vol" comme tu dis en utilisant quelques conventions
de nommage des champs dans les tables de hachage pour faciliter les
choses. Ou alors utiliser les nombreux modules permettant de créer et
gérer des classes.
Il faut bien voir que, contrairement au C (et à plein d'autres
langages), Perl est un langage dynamique. On peut quasiment tout
changer au vol : même un objet (en fait une référence bénie) peut
changer de classe (à ma connaissance, c'est le seul langage qui le
permette). La notion de structure de données est quelque chose de trop
figée. ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
Continuant ma découverte des structures de données non-triviales en Perl, je me rends compte qu'à l'usage ça me manque vachement l'équivalent d'un fichier .h en C où il y aurait (entre autres) toutes les définitions (avec typedef) des structures de données utilisées.
Les fichiers .h du C n'existent que pour des raisons techniques d'implémentation. Dans le cas des structures de données, ça permet au compilateur de connaître l'organisation et le type de chacun des éléments d'une structure.
L'aspect documentaire n'est qu'un effet secondaire involontaire.
J'ai l'impression qu'en Perl les structures de données sont construites à la volée et que donc la définition des structures est éparpillée dans le code lui-même et du coup plus tard quand j'utilise les données je me souviens pas toujours comment elles étaient structurée alors que si j'avais une bonne vieille définition de type sous les yeux, ça irait mieux.
Voyez-vous ce que je veux dire ? Si oui, comment gérez-vous ça ?
Comme toujours en Perl, il n'y a pas de méthodes générales pour gérer cela.
On peut faire "au vol" comme tu dis en utilisant quelques conventions de nommage des champs dans les tables de hachage pour faciliter les choses. Ou alors utiliser les nombreux modules permettant de créer et gérer des classes.
Il faut bien voir que, contrairement au C (et à plein d'autres langages), Perl est un langage dynamique. On peut quasiment tout changer au vol : même un objet (en fait une référence bénie) peut changer de classe (à ma connaissance, c'est le seul langage qui le permette). La notion de structure de données est quelque chose de trop figée. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
espie
In article <gajrm5$18fs$, mpg wrote:
Re-bonjour,
question plus méthodologique que technique cette fois.
Continuant ma découverte des structures de données non-triviales en Perl, je me rends compte qu'à l'usage ça me manque vachement l'équivalent d'un fichier .h en C où il y aurait (entre autres) toutes les définitions (avec typedef) des structures de données utilisées.
J'ai l'impression qu'en Perl les structures de données sont construites à la volée et que donc la définition des structures est éparpillée dans le code lui-même et du coup plus tard quand j'utilise les données je me souviens pas toujours comment elles étaient structurée alors que si j'avais une bonne vieille définition de type sous les yeux, ça irait mieux.
Voyez-vous ce que je veux dire ? Si oui, comment gérez-vous ça ?
En passant au niveau d'abstraction suivant, en faisant de l'objet.
C'est beaucoup plus simple et clair si tu te poses la question en terme de classes et de methodes, et que les structures deviennent un simple detail d'implementation.
Ensuite, perl possede, au moins sur CPAN, des tonnes de `meta'-packages, qui vont meme te permettre d'automatiser la creation de tes classes et des methodes les plus simples.
Le seul gros probleme, c'est comme toujours en perl: il y a tellement de facons differentes de faire que ca n'est pas toujours facile de choisir la meilleure...
In article <gajrm5$18fs$1@talisker.lacave.net>, mpg <mpg@elzevir.fr> wrote:
Re-bonjour,
question plus méthodologique que technique cette fois.
Continuant ma découverte des structures de données non-triviales en Perl, je
me rends compte qu'à l'usage ça me manque vachement l'équivalent d'un
fichier .h en C où il y aurait (entre autres) toutes les définitions (avec
typedef) des structures de données utilisées.
J'ai l'impression qu'en Perl les structures de données sont construites à la
volée et que donc la définition des structures est éparpillée dans le code
lui-même et du coup plus tard quand j'utilise les données je me souviens
pas toujours comment elles étaient structurée alors que si j'avais une
bonne vieille définition de type sous les yeux, ça irait mieux.
Voyez-vous ce que je veux dire ? Si oui, comment gérez-vous ça ?
En passant au niveau d'abstraction suivant, en faisant de l'objet.
C'est beaucoup plus simple et clair si tu te poses la question en terme
de classes et de methodes, et que les structures deviennent un simple
detail d'implementation.
Ensuite, perl possede, au moins sur CPAN, des tonnes de `meta'-packages,
qui vont meme te permettre d'automatiser la creation de tes classes et
des methodes les plus simples.
Le seul gros probleme, c'est comme toujours en perl: il y a tellement
de facons differentes de faire que ca n'est pas toujours facile de
choisir la meilleure...
question plus méthodologique que technique cette fois.
Continuant ma découverte des structures de données non-triviales en Perl, je me rends compte qu'à l'usage ça me manque vachement l'équivalent d'un fichier .h en C où il y aurait (entre autres) toutes les définitions (avec typedef) des structures de données utilisées.
J'ai l'impression qu'en Perl les structures de données sont construites à la volée et que donc la définition des structures est éparpillée dans le code lui-même et du coup plus tard quand j'utilise les données je me souviens pas toujours comment elles étaient structurée alors que si j'avais une bonne vieille définition de type sous les yeux, ça irait mieux.
Voyez-vous ce que je veux dire ? Si oui, comment gérez-vous ça ?
En passant au niveau d'abstraction suivant, en faisant de l'objet.
C'est beaucoup plus simple et clair si tu te poses la question en terme de classes et de methodes, et que les structures deviennent un simple detail d'implementation.
Ensuite, perl possede, au moins sur CPAN, des tonnes de `meta'-packages, qui vont meme te permettre d'automatiser la creation de tes classes et des methodes les plus simples.
Le seul gros probleme, c'est comme toujours en perl: il y a tellement de facons differentes de faire que ca n'est pas toujours facile de choisir la meilleure...
xavier
Paul Gaborit wrote:
même un objet (en fait une référence bénie) peut changer de classe (à ma connaissance, c'est le seul langage qui le permette)
Mmmh ... Smalltalk ne le permettait pas ? C'est loin, tout ça.
-- 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.
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
même un objet (en fait une référence bénie) peut
changer de classe (à ma connaissance, c'est le seul langage qui le
permette)
Mmmh ... Smalltalk ne le permettait pas ? C'est loin, tout ça.
--
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.
