>>absence de contrats : je ne connais pas trop cette manière de travailler, mais d'après Wikipedia, ca revient à tester des domaines de valeurs. les mots clé assert (Java 1.5) sont là pour ca, et au pire on pourra toujours utiliser le mécanisme des Exceptions si ca ne suffit pas.<<
On peut toujours faire tout dans chaque langage, le problème c'est la lourdeur du résultat.
En Eiffel, les contrats d'une classes sont hérités par les classes qui en héritent, tu peux dupliquer les assert ou dans l'assert d'un héritier appeler les assert de la superclass, mais c'est lourd.
Pour les closures, l'exemple type est pour les IHM, ou on a besoin de plein de petit bout de code a associer aux evenements, en Java c'est verbeux.
Je suis d'accord avec toi pour la complexité de la grammaire de Java, certes c'est plus compliqué qu'un Smalltalk mais beaucoup moins qu'un C++ ou un Perl.
Comme manque j'ajouterai:
-les "properties": c'est lourd toutes ces fonctions set et get
-le passage d'arguments par mots-clef.
Et pour les generic, je prefere celle de Scala qui peuvent être covariante ou contravariante.
[^] # Re: sonntag
Posté par reno . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
On peut toujours faire tout dans chaque langage, le problème c'est la lourdeur du résultat.
En Eiffel, les contrats d'une classes sont hérités par les classes qui en héritent, tu peux dupliquer les assert ou dans l'assert d'un héritier appeler les assert de la superclass, mais c'est lourd.
Pour les closures, l'exemple type est pour les IHM, ou on a besoin de plein de petit bout de code a associer aux evenements, en Java c'est verbeux.
Je suis d'accord avec toi pour la complexité de la grammaire de Java, certes c'est plus compliqué qu'un Smalltalk mais beaucoup moins qu'un C++ ou un Perl.
Comme manque j'ajouterai:
-les "properties": c'est lourd toutes ces fonctions set et get
-le passage d'arguments par mots-clef.
Et pour les generic, je prefere celle de Scala qui peuvent être covariante ou contravariante.