Commentaires

1. Le dimanche 8 février 2009, 09:31 par Charles.w

Je ne suis pas d'accord. Il s'agit juste d'une bonne habitude à prendre...d'autant que pour des raisons historiques, l'ancienne convention a de fortes chances d'être maintenue, rendant caduque la nouvelle notation...

2. Le dimanche 8 février 2009, 10:39 par Olivier Croisier

Les conventions peuvent être changées ou améliorées, pour plus de lisibilité ou une meilleure robustesse.

De la même manière, avant Java5, certains spécifiaient le type de leurs collections comme ceci :
public List /* String */ myWords;
Certes, on peut continuer à utiliser cette convention, mais la notation introduite avec Java 5 offre au moins l'avantage de la standardiser, même chez les développeurs juniors. La lisibilité et la clarté du code n'en sont que meilleures.

Du coup, pourquoi ne pas appliquer cela au 4° modificateur de visibilité ? Le mot-clé packaged pourrait, par exemple, être optionnel (pour des raisons de rétro-compatibilité notamment), mais il aurait au moins le mérite d'exister, offrant au développeur un moyen standard d'exprimer son intention dans les deux cas que j'ai présentés.

3. Le dimanche 8 février 2009, 19:42 par HollyDays

Autre solution : interdire la visibilité "package" par un outil d'analyse statique de code (du genre CheckStyle ou FindBugs dans Eclipse, ou directement dans l'EDI d'IntelliJ IDEA), et utiliser la visibilité "protected" quand on a besoin de laisser la visibilité d'un attribut ou d'une méthode aux autres classes du package (puisque, comme vous le savez certainement tous, en Java, la visibilité "protected" s'étend à toutes les autres classes du même package *et* à toutes les sous-classes de la classe courante quel que soit leur package).

4. Le dimanche 8 février 2009, 20:35 par Olivier Croisier

Interdire carrément la visibilité package, ce n'est pas un peu extrême ? Il y a quand même des cas où "protected" est trop permissif...

Par contre, faire en sorte que les outils d'analyse statique émettent un warning en cas d'absence de modificateur de visibilité, ça semble intéressant. Et du coup, le mot-clé packaged prendrait tout son sens.

5. Le lundi 9 février 2009, 09:45 par HollyDays

On peut se débrouiller sans ajouter un mot-clé, mais plutôt une annotation dédiée (ou un @SuppressWarnings("package-visibility")) : l'outil d'analyse de code n'émettrait alors de warning qu'en l'absence de cette annotation.

6. Le lundi 9 février 2009, 10:58 par Olivier Croisier

On pourrait effectivement faire comme ça, mais cela ne fonctionnerait pas sur le code auquel on n'a pas accès (libs, frameworks...).
Je pensais également à AspectJ, où actuellement, pour exprimer un pointcut sur une méthode de visibilité "package", il faut écrire :
execution(!private !public !protected * *(..));
Ce qui est quand même assez lourd...

7. Le mardi 10 février 2009, 08:42 par ptitbob

Bonjour,
Je suis assez d'accord avec l'ajout du mot clef packaged, l'absence ne devrait indiqué qu'une visibilité privée. C'est quand même plus propre !!! ;)
Cordialement

8. Le mardi 10 février 2009, 18:26 par AA

Moi je suis pour l'introduction de ce mot clef et aussi pour restreindre la visibilité de protected aux classes filles seulement.
En fait revenir au tout début de java, où il était possible (je crois) de faire des méthodes avec les modifiers package et protected.

9. Le jeudi 25 juin 2009, 19:24 par zorro

Je suis assez d'accord avec l'ajout du mot clef packaged, l'absence ne devrait indiqué qu'une visibilité privée.
Je suis d'accord avec ptitbob