>>- pas de réflexivité
>Ce choix a été fait pour simplifier la machine virtuelle et pour des raisons de sécurités >(si tu as le droit de modifier les classes de sécurités ou les classloaders, t'es mal).
D'une part il ne faut jamais mélanger implémentation et langages. La réflexivité est une torture à compiler en natif, avec une marchine virtuelle cela ne devient que très très difficile et peu efficace. Mais j'ai bien précisé que je ne parlait que du langage et pas de son implémentation.
Le langage Java est le même qui est utilisé par les compilateurs natifs (tel gcc) et la machine virtuelle peut faire tourner du byte-code qui ne provient pas d'un programme en Java (SmartEiffel peut produire du byte code JVM). Le langage Java n'est pas lié à la JVM.
Ensuite, que Java ne fasse pas de réflexivité c'est pas non plus la fin du monde. C'est déjà vachement bien qu'on aie l'introspection je trouve.
Pour conclure, rien n'empeche que le gestionnaire de sécurité soit en read-only et qu'il vérifie les modifications apportés au système.
>>- pas de fonctions lambda :) ;
>Ces fonctions sont émulés par les objets et les interfaces. exemple : l'interface >java.util.Comparator qui définit une méthode public int compareTo(Object o1, Object >o2). Tu crées une classe implémentant Comparator (de type inner, toplevel ou >anonyme) avec ta méthode de tri et tu la passe à la méthode voulue (Arrays.sort() >par ex). Ca marche pareil avec les Iterator, les Enumeration, etc.
Arg !
Je savais pas ça. C'est terriblement lourd comme système. Forcer la création d'une classe avec une méthode particulière pour charque fonction de comparaison est monstrueux. Sans compter que d'une part pour que le typage accepte ça il faut faire des coercition à tout va et d'autre par ce n'est plus la classe d'origine qui est responsable des ses comparaisons mais un autre classe.
Un solution simple pour faire ça serait quelque chose du genre :
creer une méthode par comparaison dans la classe.
class Persone
{
int compare_by_name() {...}
int compare_by_age() {...}
}
le container possédant une méthode de tri qui necessite une méthode de comparaions
class Container
{
void sort_using(Function comparator) {...}
}
D'une part il me semble que c'est faisable avec l'introspection Java et d'autre part Java aurait à y gagner en spécifiant ce genre de trucs correctement (SmartEiffel fait ça de façon originale et plutot pas mal) et pas par des stratagèmes qui pervertissent notre belle jeunesse !
>Je trouve que ça a l'avantage de clarifier le language (au détriment peut-etre de la >rapidité d'écriture et encore).
méthode coué, hein ?
>>- pas de contrats
>Conceptuellement, je suis d'accord, c'est un gros manque. Mais qui va coder les tests >des contrats dans ses classes à part ceux qui font des choses carrées ? (j'ai deux >exemples sous la main de codeurs non propres, je les imaginent mal utiliser les >contrats).
Les contrats publics sont construits lors de la spécification en même temps que l'interface. En plus de les écrire sur un bout de parier ou dans un graphe UML tu les ajoute dans ton code.
Si tes codeurs non propres sont incapable d'utiliser les contrats, je les vois mal utiliser l'autodocumentation, les commentaires ou les assertions.
Les contrats c'est fait pour faire des trucs carrés avec un accord entre plusieurs entités (entre classes, entre développeurs, entre donneur d'ordre et fournisseur). D'ailleurs le nom n'est pas annodin.
> Pour ce qui est des noms longs, ça a l'avantage d'etre lisible et compréhensible
> (compare strftime() et DateFormat.format()). L'inconvénient, je le reconnais, c'est
> cette lignes des 80 colonnes qu'on atteint voire franchit allègrement.
[^] # Re: Java et Linux
Posté par MrTout . En réponse au journal Java et Linux. Évalué à 2.
>Ce choix a été fait pour simplifier la machine virtuelle et pour des raisons de sécurités >(si tu as le droit de modifier les classes de sécurités ou les classloaders, t'es mal).
D'une part il ne faut jamais mélanger implémentation et langages. La réflexivité est une torture à compiler en natif, avec une marchine virtuelle cela ne devient que très très difficile et peu efficace. Mais j'ai bien précisé que je ne parlait que du langage et pas de son implémentation.
Le langage Java est le même qui est utilisé par les compilateurs natifs (tel gcc) et la machine virtuelle peut faire tourner du byte-code qui ne provient pas d'un programme en Java (SmartEiffel peut produire du byte code JVM). Le langage Java n'est pas lié à la JVM.
Ensuite, que Java ne fasse pas de réflexivité c'est pas non plus la fin du monde. C'est déjà vachement bien qu'on aie l'introspection je trouve.
Pour conclure, rien n'empeche que le gestionnaire de sécurité soit en read-only et qu'il vérifie les modifications apportés au système.
>>- pas de fonctions lambda :) ;
>Ces fonctions sont émulés par les objets et les interfaces. exemple : l'interface >java.util.Comparator qui définit une méthode public int compareTo(Object o1, Object >o2). Tu crées une classe implémentant Comparator (de type inner, toplevel ou >anonyme) avec ta méthode de tri et tu la passe à la méthode voulue (Arrays.sort() >par ex). Ca marche pareil avec les Iterator, les Enumeration, etc.
Arg !
Je savais pas ça. C'est terriblement lourd comme système. Forcer la création d'une classe avec une méthode particulière pour charque fonction de comparaison est monstrueux. Sans compter que d'une part pour que le typage accepte ça il faut faire des coercition à tout va et d'autre par ce n'est plus la classe d'origine qui est responsable des ses comparaisons mais un autre classe.
Un solution simple pour faire ça serait quelque chose du genre :
creer une méthode par comparaison dans la classe.
class Persone
{
int compare_by_name() {...}
int compare_by_age() {...}
}
le container possédant une méthode de tri qui necessite une méthode de comparaions
class Container
{
void sort_using(Function comparator) {...}
}
D'une part il me semble que c'est faisable avec l'introspection Java et d'autre part Java aurait à y gagner en spécifiant ce genre de trucs correctement (SmartEiffel fait ça de façon originale et plutot pas mal) et pas par des stratagèmes qui pervertissent notre belle jeunesse !
>Je trouve que ça a l'avantage de clarifier le language (au détriment peut-etre de la >rapidité d'écriture et encore).
méthode coué, hein ?
>>- pas de contrats
>Conceptuellement, je suis d'accord, c'est un gros manque. Mais qui va coder les tests >des contrats dans ses classes à part ceux qui font des choses carrées ? (j'ai deux >exemples sous la main de codeurs non propres, je les imaginent mal utiliser les >contrats).
Les contrats publics sont construits lors de la spécification en même temps que l'interface. En plus de les écrire sur un bout de parier ou dans un graphe UML tu les ajoute dans ton code.
Si tes codeurs non propres sont incapable d'utiliser les contrats, je les vois mal utiliser l'autodocumentation, les commentaires ou les assertions.
Les contrats c'est fait pour faire des trucs carrés avec un accord entre plusieurs entités (entre classes, entre développeurs, entre donneur d'ordre et fournisseur). D'ailleurs le nom n'est pas annodin.
> Pour ce qui est des noms longs, ça a l'avantage d'etre lisible et compréhensible
> (compare strftime() et DateFormat.format()). L'inconvénient, je le reconnais, c'est
> cette lignes des 80 colonnes qu'on atteint voire franchit allègrement.
c'est pour ça qu'il y à un juste milieu entre
p "hello world"
et
system.out.screen.display.string.print_ended_with_a_new_line("hello word");
:p
Le but pas d'avoir des noms longs ou des noms courts mais des noms explicites !