définitions de structures de données ?
mpg
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 ?
Merci,
Manuel.
Paul Gaborit
À (at) Sun, 14 Sep 2008 22:20:20 +0200,
mpg <m...@elzevir.fr> écrivait (wrote):
> 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/>
Marc Espie
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...
Paul Gaborit
À (at) Mon, 15 Sep 2008 20:48:00 +0200,
xav...@groumpf.org (Xavier) écrivait (wrote):
> Paul Gaborit <Paul.G...@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)
>
Oui, effectivement, j'avais oublié Smalltalk.