Discussion :

[bassim]

(surtout pour éviter que la proposition 2 soit retenue dès fois que ça passerait)

impossible, les gars de Java attendent notre accord pour effectuer les changements

[xavlours]

Pour paraphraser une signature, je dirai : "un code crade en C++ est humain, mais une véritable catastrophe nécessite un typedef". Encore que les pires horreurs combinent typedef, pointeurs et const, et on en est à l'abri en java, mais non. C'est la porte ouverte à toutes les fenêtres, et les grueeks (mi geek mi cochon) vont s'y ruer joyeusement.

Bon c'est vrai que les arguments d'adiguba tiennent la route, mais j'ai encore de trop mauvais souvenirs.

[azalsup]

Au risque de me repeter ca marche tres bien en python donc ca sera une avancé pour le JAVA

exemple en python

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
import os.path as manipdir

pythonesquement pour

[bulbo]

Au risque de me repeter ca marche tres bien en python donc ca sera une avancé pour le JAVA

exemple en python

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
import os.path as manipdir

pythonesquement pour

Mais pourquoi transformer java en python?? Si tu aimes tant python, utilise le et respecte java pour ce qu'il est, un langage objet propre et facilement lisible.

Bulbo

[Tommy31]

Pour, c'est dans la suite logique de l'ajout des générics en laissant la possibilité d'exprimer de nouvelles dénotations sans être obligé de faire un héritage vide (de nommage). Cas rencontré assez fréquemment quand on joue avec des foncteurs.

[azalsup]

La questio n'est pas d'aimer un langage ou un autre.

Java doit evoluer, java n'est pas python, mais si des langages comme python (qui se sont d'ailleur largement inspiré du java) ont des fonctionalités interessantes , pourquoi les ignorer.

Le java doit evoluer pour faire face au c# (meme si ce dernier n'a aucune chance de detroner le java dans nos coeurs)

Mais pourquoi transformer java en python?? Si tu aimes tant python, utilise le et respecte java pour ce qu'il est, un langage objet propre et facilement lisible.

Bulbo

[natha]

Donner trop de souplesse de programmation serait une erreur.
Cette proposition n'a que peu d'intérêt et on peut s'en passer sans le moindre problème même s'il faut peut-être créer une classe de plus. Mais créer une classe de plus permettra d'avoir une javadoc adaptée et une meilleure compréhension du but final.
Le typedef n'a pas vraiment de sens en java sauf peut-être pour les éléments génériques et encore, si c'est juste pour simplifier le nom je trouve que les autres propositions sont plus adaptées que celle-ci.

Le java doit evoluer pour faire face au c#

La faiblesse de java n'est pas au niveau grammaire mais plutôt au niveau des librairies pas assez puissantes sur certains points maintenant devenus à la mode. Il y a de cruels manques en Swing par exemple pour ne citer que ça.

[bulbo]

La questio n'est pas d'aimer un langage ou un autre.

Java doit evoluer, java n'est pas python, mais si des langages comme python (qui se sont d'ailleur largement inspiré du java) ont des fonctionalités interessantes , pourquoi les ignorer.

Le java doit evoluer pour faire face au c# (meme si ce dernier n'a aucune chance de detroner le java dans nos coeurs)

Oula molo, c'est pas la course à l'échalote. Le C# a introduit tout un tas de saloperie que je n'ai surtout pas envie de voir débarquer dans Java.

Si java a fonctionné aussi bien, c'est que les objectifs étaient clair: un langage objet clair et débarrassé des choses dangereuses ou piégeuses vu dans le C++ par exemple.

La ou java à encore de la marge de progression c'est surtout dans la puissance des machines virtuelles, l'intégration au desktop et bien sur les librairies qui seront disponibles pour ce langage.

Les gadgets syntaxiques pour économiser 3 caractères ou avoir l'air cool comme les nouveaux langages à la mode (C#, python ..) désolé mais ça n'apporte rien de plus. Attention j'ai pas dis que les propositions de Sun n'apportaient rien de nouveau, certaines si, d'autres pas.

Un langage n'est pas un voiture qu'on tune au fur et à mesure qu'on s'en lasse, il se doit d'avoir une stabilité, une syntaxe lisible et des règles strictes afin de guider le développeur. Beaucoup des nouvelles propositions pour moi ne vont pas dans ce sens.

Bulbo

[adiGuba]

Java doit evoluer, java n'est pas python, mais si des langages comme python (qui se sont d'ailleur largement inspiré du java) ont des fonctionalités interessantes , pourquoi les ignorer.

Ce qu'il veut dire par là c'est que ce n'est pas parce que ce cela existe dans un autre langage que cela doit être ajouté à Java...

La discussion ne doit pas être :

• Python (ou un autre langage) possède cette fonctionnalité, donc Java doit l'avoir

Mais plutôt :

• Quels avantages (et éventuellement inconvénients) apporteraient cette fonctionnalité à Java

Bien sûr on peut très bien se baser sur l'expérience d'autre langage qui possèderait cette fonctionnalité, mais la simple présence de la fonctionnalité dans d'autre langage n'est pas vraiment un argument...


La force de Java est justement dans son langage simple mais puissant : si on ajoute un fonctionnalité il faut vraiment que cela apporte quelque chose pour que ce soit intéressant, afin que le gain soit plus important que la complexité que cela pourrait apporter...



Bien qu'ayant voté pour cette proposition, je pense que les contres-arguments qui ont été donné sont plutôt sensé et que ces typedef pourraient s'avérer très dangereux s'ils sont mal utilisé (surtout qu'il ne concernerait qu'un fichier *.java et que l'on pourrait avoir des noms identiques qui représenterait des types différents selon les fichiers sources).


De plus il s'agit quand même d'un problème relativement rare... (pour un peu et je changerais presque d'avis)

a++

[Deadpool]

Oula molo, c'est pas la course à l'échalote. Le C# a introduit tout un tas de saloperie que je n'ai surtout pas envie de voir débarquer dans Java.

Des exemples?

[bulbo]

Des exemples?

De tête je ne pourrais plus te citer d'exemples précis, mais à mon avis visite un thread genre C# vs java et tu en trouveras autant que tu veux.

J'avais fait le tour vite fait à la sortie du C# pour faire la comparaison avec java et j'étais tombé sur des trucs pas vraiment objet (ou même pas du tout), sur des trucs sales permettant plein de cochonneries du genre de celles qui font de C++ le langage le plus aimé/détesté de tous

Je suis pas un expert C# désolé, juste un trolleur java et le langage C# ne m'intéressant pas du tout, je ne perdrai pas mon temps à te rechercher les perles que j'avais trouvées à l'époque

Bulbo

[adiGuba]

De tête je ne pourrais plus te citer d'exemples précis

Moi j'en ai un : le goto

a++

[Deadpool]

J'avais fait le tour vite fait à la sortie du C# pour faire la comparaison avec java et j'étais tombé sur des trucs pas vraiment objet (ou même pas du tout), sur des trucs sales permettant plein de cochonneries du genre de celles qui font de C++ le langage le plus aimé/détesté de tous

Ok, dommage.

C'était les Struct qui te gênaient peut être?

Ou alors le fait qu'il faille déclarer les méthodes comme virtuelles pour utiliser le polymorphisme?

Enfin bref, on va peut refaire C# versus Java ici, ce n'est pas le sujet.

Moi j'en ai un : le goto

a++

Et ne parlons pas de la surcharge d'opérateur.

[Pill_S]

Personnellement, je pense qu'il s'agit d'une très mauvaise proposition!

Je pense qu'on se retrouverait vite avec des gens qui n'aiment pas manipuler les types par défaut (éloignés de leurs habitudes venant d'autres languages), et se font leurs propres parallèles... Imaginez ce genre de code...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
import java.lang.Integer as Number;
import java.lang.Double as Real;
import java.lang.String as Text;
import java.io.File as ...;
...

Vous perdez vite toute cohérence, chacun peut faire sa soupe à lui...

Et concernant les conflits de noms, je pense qu'ils sont sont bien trop rares pour être préoccupants... Ce n'est pas tous les jours que je dois utiliser 2 types Date différents à l'intérieur d'une même classe. Et quand cela arrive, autant les nommer complètement chacune.

Côté maintenance les alias sont catastrophiques...

[kenji_getpowered]

j'ai voté contre

les cas ou les conflits arrivent sont trop rares et je pense également que cela peut nuire à la lisibilité du code

[denisC]

Mais pourquoi transformer java en python?? Si tu aimes tant python, utilise le et respecte java pour ce qu'il est, un langage objet propre et facilement lisible.

+1 avec bulbo.

J'utilise les deux, et je dois dire que la syntaxe longue du Java permet de le rendre bien plus compréhensible.

En python, je fait ems scripts parceque ça va vite a écrire, mais je mets au défi qui que ce soit de tenter de les maintenir

A mon avis, on a besoin de plusieurs langage. Je vois bien Java comme un langage a la syntaxe trés explicite (un peu lourd a écrire, mais mon IDE écrit plus de code que moi), et python comme quelque chose de plus simple, mais moins maintenable au bout d'un moment.

Donc contre, et tant pis pour les Dates

[lunatix]

proposition 1 si ca marche avec les import static !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

import static java.util.Calendar.getInstanceas as now

[cysboy]

Je suis pour !
Et celà pour les mêmes raisons qu'a emis adiGuba dans le spremières pages !

[nicorama]

J'aimerais bien truc du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
MyChildList as ArrayList implements ChildList;
MyChildList myChildList=new MyChildList(){
   //implementation des fonctions de l'interface
}

Car pour l'instant je doit créer un package contenant les classes implémentant ChildList. Et je commence à avoir beaucoup de fichiers - ou alors ya une instruction Java que j'ai zappé.
MyChildList n'est pas une classe public à proprement parlé, mais pas vraiment privée non plus. il faudrait réécrire 'MyChildList as ArrayList implements ChildList;' chaque fois qu'on en a besoin, ou 'MyChildList as AbstracList<Eleve> implements ChildList;', tout polymorphisme, generics et autres trucs objets étant possibles.

[kisame]

Bien utilisés les typedef sont une vraie bénédiction.
mal utilisé -->

un peu de rigueur n'a jamais fait de mal à personne. totalement pour mais il va falloir changer notre façon de travailler.
Ca me manquait les typedef
peu importe l'implémentation. Je préfère la première proposition quand même.

[HS c++]

Encore que les pires horreurs combinent typedef, pointeurs et const

En quoi le const combiné à n'importe quoi ferait qu'un code soit porc ? C'est au contraire un sacré gain en terme de rigueur de code. C'est quand même un gros manque dans tout langage qui se veut propre et/ou rigoureux. Autant on peut critiquer le c++ sur des milliards de points et il serait totalement indéfendable autant que java dispose d'un mot clé const inutilisé et qu'on soit obligé de recourir à des bidouilles pour faire un truc qui s'en rapproche ... ça fait vraiment cheap et mal fini pour un tel langage.
[/HS c++]