J'ai rien contre, mais je ne vois pas l'intérêt. Donc plutot contre pour éviter de faire de l'ombre aux vrai nouvelles propositions utiles de Java7
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
J'ai rien contre, mais je ne vois pas l'intérêt. Donc plutot contre pour éviter de faire de l'ombre aux vrai nouvelles propositions utiles de Java7
J'aime bien la proposition 2 : This, classe de l'objet this. Ca suit la notation conseillée pour Java, c'est très clair, je trouve.
Pour la proposition 2, mais pas pour les appels chaînés, plutôt pour des méthodes comme clone().
C'est juste que j'ai toujours été frustré de me faire ch... à bien vérifier mes generics, et à quand même me taper les warnings à cause d'un clone. C'est pas pour faire mon râleur, c'est juste que je trouve l'illustration mal choisie. Je suis pas fan des appels chaînés, mais l'utilisation d'un type This combiné avec les generics peut apporter de l'expressivité (je crois).
Hum en effet cela pourrait être vraiment pas mal !Envoyé par xavlours
Par contre je me demande s'il est possible de modifier la définition de clone() sans casser la compatibilité...
a++
En théorie, ça devrait être faisable, puisque l'objet renvoyé par clone() doit être du même type que l'objet d'origine. Mais rien ne le garantit à la compilation (ni même à l'exécution).Par contre je me demande s'il est possible de modifier la définition de clone() sans casser la compatibilité...
On peut imaginer une implémentation de List tellement exotique (ou crade) que le développeur décide de renvoyer une ArrayList ou une LinkedList lors du clone. Si cette List est fournie par une Factory, l'utilisateur ne s'en rendra même pas compte à l'exécution, puisqu'il manipule une List, et qu'il caste son clone en List. Par contre, le jour du changement de JRE, ça plante.
Mais tant pis pour eux, je suis toujours pour.
Ca pourrait être pas mal car la syntaxe des generics style
ByteBuffer extends Buffer<ByteBuffer>
ou la classe se passe elle même en paramètre de sa mère est un peu moche par contre un mot clef différent de this serait le bienvenu, peut être un <this> pour bien différencier les 2 non ?
Voté pour la proposition 1 (pas la 2) comme ça, on évite d'ajouter un nouveau mot clé/type et on évite de casser ceux qui ont eu la malchance de nommer un de leurr type par
This.
Voté pour en général car ça permet de bâtir des APIs plus solides et extensibles: ça peut ne pas intéresser ceux qui mangent leur propre côde, mais dans les cas où on batît une couche sur laquelle d'autres bâtiront leur propre couche, etc., cette fonctionnalité est un must !
P.S.: J'ai voté contré le chainage des appels void.
En fait, ni l’une ni l’autre ne me séduisent.
Niveau maintenance, je pense que le cast obligatoire a ses vertus.
Je suis donc contre.
Contre.
Je pense qu'un cast obligatoire soit pus lisible!
"Un remboursement des programmes défectueux serait envisageable mais toute l'industrie du logiciel ferait faillite la première année." Andrew Tanenbaum.
Alors, si jamais ça se fait:
- contre l'obligation de retourner l'objet courant.
- contre l'obligation de retourner un objet exactement du même type dynamique que this. Une sous-classe peut et doit faire l'affaire.
- pour la stricte obligation de surcharger la méthode dans toutes les sous-classes (comme une méthode abstract), et en plus dans toutes les sous-sous-classes. Ma classe MatriceCarree immuable ne peut pas hériter implicitement de la méthode Matrice{ This inverser(){blabla} }, je dois impérativement la surcharger pour instancier proprement une instance de MatriceCarree .
Pour info, le langage Eiffel possède un type "like current" à peu près cohérent.
Contre : La syntaxe de Java est lourde, mais cela fait qu'elle est claire.
Si je veux un langage ou mon programme tienne en une ligne, je prendrais Perl.
A mon avis, tout ces nouvelles possibilités vont faire qu'au final on aura 2560 facons d'ecrire la même chose, ce qui au final rendra la compréhension d'un programme donné difficile, si on a pas les mêmes habitudes que celui qui l'a écrit.
Je trouve ca fou que d'un coté les gens mettent en place des tonnes de conventions de codage, de regles et tout, et pendant ce temps Sun nous invente des nouvelles notations a tour de bras, juste pour sauver un petit cast, et pouvoir ecrire 12 instructions en une seule ligne.
j'adhère d'une façon générale a ton raisonnement.
La seule proposition interressante à mon gout est la "JDK 7: Proposition 1 : Constructeurs simplifiés pour la généricité".
JBusyComponent, une API pour rendre occupé un composant swing.
SCJP Java 6.0 (90% pass score)
Je ne suis pas sur que SUN est derrière ces propositions. Il me semble qu'il s'agit de proposition de la communauté et que c'est le JCP qui rédige le JLS maintenant.
OpenJDK est la communauté qui gère l'implémentation de référence défini par le JCP.
A part la propriété intellectuelle de l'appellation Java, je ne sais pas s'il reste grand chose à SUN.
Sun garde quand même une place de choix dans les JCP. Mais il est vrai que toutes ces propositions ne viennent pas de Sun.
Tu as tout a fait raison, Christophe. Mais c'est quand même Joshua qui présente, donc Sun n'est pas bien loin.
Mais il faudrait effectivement dire JCP plutot que SUN. Enfin a part le nom, mon avis reste le même. Pourquoi chercher a tout prix a simplifier une syntaxe qui a pour le moment l'avantage de la clareté? Ca me parait être se tirer une balle dans le pieds que de supprimer ce gros avantage de Java...
Joshua travaille désormais chez Google il me semble...
Sinon cette proposition me semble au contraire apporté plus de clarté, en distinguant le cas où retourne un objet du même type et le cas où l'on renvoi l'instance courante...
a++
De plus, c'est surtout Neal Gafter qui propose cela. Même pas Joshua. Et tous les deux sont chez Google.
Vincent
Vincent Brabant
Ne pas me contacter par MP ni par mail pour des questions techniques. Ma liste d'amis restera vide.
Cours et tutoriels pour apprendre Java , FAQ Java, et Forum Java
Après avoir un moment hésité, contre.
Si on était obligé de faire un cast ça se justifierait, mais ce n'est pas le cas. On peut très bien surcharger les méthodes concernées dans la classe fille pour qu'elles retourne le type souhaité, comme l'explique AdiGuba ici.
Je pense que c'est à la classe fille de savoir quel type elle veut retourner, pas sa classe mère.
Au contraire je pense que c'est à la classe mère (ou à l'interface) de définir le type qu'il sera retourné. Mais actuellement il n'y a aucune moyen de dire "tu dois retourner this"...
a++
L'assertion obligeant a retourner "this" fait elle vraiment partie de l'API ?
Je m'explique.
Prenons le cas du mot clef "synchronized" qui est aujourd'hui considéré uniquement comme du ressort de l'implémentation. A tel point que la javadoc ne tient pas compte de ce mot clef et ne sera donc jamais commenté lors de la publication de l'API.
J'ai l'impression que retourner "this" plutot qu'une nouvelle instance dans une méthode à l'instar du mot clef "synchronized" fait plutôt partie du domaine de l'implémentation et non de l'API.
Je ne ressens pas le besoin de pouvoir exprimer "retourne this"
Par contre pouvoir exprimer "retourne le même type que la vision que j'ai de l'objet" est interressant et améliorerait bien l'utilisation du polymorphisme.
JBusyComponent, une API pour rendre occupé un composant swing.
SCJP Java 6.0 (90% pass score)
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager