Je connais pas grand chose au Lisp mais en gros ca s'apparente à une table de hachage comme une pratique courante en Python
Tu peux adopter avec Java aussi cette solution de facilité même si ce n'est pas supporté par la syntaxe du langage, tout les retours de paramètres multiples ne sont rien d'autre que des tuples en Python
Juste qu'on t'explique que dans le monde objet on préférera utiliser un vrai type de données, une classe en guise de retour qui supporte le contrat et rien que le contrat. On garantit l'encapsulation dès le départ.
Si tes besoins évoluent par la suite,
genre je rajoute, un troisième champ eh ben c'est vrai avec un Hashmap .... l'ancien code appelant marche toujours.
Maintenant je veux pouvoir pouvoir rajouter des comportement à ce résultat comme par exemple le rendre sérialisable. .... et puis on s'aperçoit que finalement la table de hachage c'est pas si bien que ca parce que ca rame parce qu'il manque des trucs ou simplement parce tien un nouveau type qui fait tout ca existe dans le langage
Les sets python sont bien utiles mais n'existaient pas dasn les premières versions http://docs.python.org/library/sets.html
soit on surcharge alors les Hash qui devient un vrai type.
Avec Python tu vas commencer a surcharger les built'in types, ...
Mais dès le départ tu as fait un choix sur la structure de donnée , peu importe que cette structure fasse partie intégrante du langage ou non.
Or mon contrat disait que je voulais getMin, GetMax,GetMinMax et pas getKeys, get Values, getDict...
Manque de bol, partout dans mon code appelant je les ai utilisés et maintenant que j'ai choisi d'utiliser des Sets, je suis marron.
En plus ma lib a été diffusée et j'oblige également tous mes clients à s'aligner.
Je suis d'accord, est-ce que le jeu en vaut la chandelle , tout est affaire de compromis entre résultat à court terme et évolutivité.
Je suis d'accord que, qui peut le plus peut le moins et qu'un langage plus souple n'empêche pas la rigueur.
Mais il ne faut pas sacrifier les bonnes pratiques.
[^] # Re: javascript
Posté par Bozo_le_clown . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 2.
Tu peux adopter avec Java aussi cette solution de facilité même si ce n'est pas supporté par la syntaxe du langage, tout les retours de paramètres multiples ne sont rien d'autre que des tuples en Python
Juste qu'on t'explique que dans le monde objet on préférera utiliser un vrai type de données, une classe en guise de retour qui supporte le contrat et rien que le contrat. On garantit l'encapsulation dès le départ.
Si tes besoins évoluent par la suite,
genre je rajoute, un troisième champ eh ben c'est vrai avec un Hashmap .... l'ancien code appelant marche toujours.
Maintenant je veux pouvoir pouvoir rajouter des comportement à ce résultat comme par exemple le rendre sérialisable. .... et puis on s'aperçoit que finalement la table de hachage c'est pas si bien que ca parce que ca rame parce qu'il manque des trucs ou simplement parce tien un nouveau type qui fait tout ca existe dans le langage
Les sets python sont bien utiles mais n'existaient pas dasn les premières versions
http://docs.python.org/library/sets.html
soit on surcharge alors les Hash qui devient un vrai type.
Avec Python tu vas commencer a surcharger les built'in types, ...
Mais dès le départ tu as fait un choix sur la structure de donnée , peu importe que cette structure fasse partie intégrante du langage ou non.
Or mon contrat disait que je voulais getMin, GetMax,GetMinMax et pas getKeys, get Values, getDict...
Manque de bol, partout dans mon code appelant je les ai utilisés et maintenant que j'ai choisi d'utiliser des Sets, je suis marron.
En plus ma lib a été diffusée et j'oblige également tous mes clients à s'aligner.
Je suis d'accord, est-ce que le jeu en vaut la chandelle , tout est affaire de compromis entre résultat à court terme et évolutivité.
Je suis d'accord que, qui peut le plus peut le moins et qu'un langage plus souple n'empêche pas la rigueur.
Mais il ne faut pas sacrifier les bonnes pratiques.