C'est une absence mineure, comme celle du switch case.
Je préfère cela à une absence majeure comme celle des fonctions comme objets à part entière.
Note que vouloir opposer Java à Python pour la concision du code est perdu d'avance de toute façon.
Oui rejetons tout ce qui pemet d'apporter de la qualité aux developpement: les contrats, le typage fort, les GC.
Python a le typage fort et le GC.
Il lui manque certes les "contrats" (mais Java les a-t-il ? hmmm ?).
Note qu'avec un peu d'imagination, tu pourrais faire une bibliothèque de contrats pour Python avec des décorateurs de fonctions. Je crois même que ça existe, mais j'ai la flemme de vérifier.
Le problème a résoudre est que je cherche le mot clé protected et non private.
Mais encore une fois, l'utilité d'une méthode se spécifie par la documentation, pas en ajoutant des mots-clés à qui mieux-mieux pour contrôler les accès. Un langage de programmation n'est pas un OS (quoiqu'au début, on nous prédisait littéralement que Java deviendrait l'OS ; j'imagine que dans cette optique il fallait garantir programmatiquement la protection des accès à chaque composant...).
En d'autres termes :
- soit ta méthode est privée et tu la préfixes par un underscore, la signification étant évidente
- soit ta méthode est destinée aux classes dérivées, et tu l'expliques dans la documentation (vu que de toute façon, il faut bien documenter tout ce qui est non-privé, n'est-ce pas ?)
Sinon va faire un tour sur les annonces d'emploi des devs Java et tu verras comme ils sont sous-payés.
Mmmh ?
Java a bien été conçu dans l'optique où le programmeur fait beaucoup de bêtises et où il faut une tonne de mécanismes impératifs pour le forcer à faire les choses correctement. C'est pour ça que c'est un langage très rigide et très verbeux.
Il ne faut pas croire aux fables de l'informatique d'entreprise : si Java s'est imposé en entreprise, ce n'est pas simplement parce qu'il y a un GC et un typage fort...
Java fait croire qu'il permet de tayloriser le travail de programmation, et donc de former des "informaticiens" à la chaîne dans l'optique de baisser les coûts. Evidemment en pratique un programmeur compétent est toujours nécessaire pour faire du bon code ; et un programmeur compétent est en général au moins aussi productif en Python (ou Ruby, etc.) qu'en Java. Hum.
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 3.
C'est une absence mineure, comme celle du switch case.
Je préfère cela à une absence majeure comme celle des fonctions comme objets à part entière.
Note que vouloir opposer Java à Python pour la concision du code est perdu d'avance de toute façon.
Oui rejetons tout ce qui pemet d'apporter de la qualité aux developpement: les contrats, le typage fort, les GC.
Python a le typage fort et le GC.
Il lui manque certes les "contrats" (mais Java les a-t-il ? hmmm ?).
Note qu'avec un peu d'imagination, tu pourrais faire une bibliothèque de contrats pour Python avec des décorateurs de fonctions. Je crois même que ça existe, mais j'ai la flemme de vérifier.
Le problème a résoudre est que je cherche le mot clé protected et non private.
Mais encore une fois, l'utilité d'une méthode se spécifie par la documentation, pas en ajoutant des mots-clés à qui mieux-mieux pour contrôler les accès. Un langage de programmation n'est pas un OS (quoiqu'au début, on nous prédisait littéralement que Java deviendrait l'OS ; j'imagine que dans cette optique il fallait garantir programmatiquement la protection des accès à chaque composant...).
En d'autres termes :
- soit ta méthode est privée et tu la préfixes par un underscore, la signification étant évidente
- soit ta méthode est destinée aux classes dérivées, et tu l'expliques dans la documentation (vu que de toute façon, il faut bien documenter tout ce qui est non-privé, n'est-ce pas ?)
Sinon va faire un tour sur les annonces d'emploi des devs Java et tu verras comme ils sont sous-payés.
Mmmh ?
Java a bien été conçu dans l'optique où le programmeur fait beaucoup de bêtises et où il faut une tonne de mécanismes impératifs pour le forcer à faire les choses correctement. C'est pour ça que c'est un langage très rigide et très verbeux.
Il ne faut pas croire aux fables de l'informatique d'entreprise : si Java s'est imposé en entreprise, ce n'est pas simplement parce qu'il y a un GC et un typage fort...
Java fait croire qu'il permet de tayloriser le travail de programmation, et donc de former des "informaticiens" à la chaîne dans l'optique de baisser les coûts. Evidemment en pratique un programmeur compétent est toujours nécessaire pour faire du bon code ; et un programmeur compétent est en général au moins aussi productif en Python (ou Ruby, etc.) qu'en Java. Hum.