Discussion :

[_skip]

C'est d'ailleurs bizarre qu'il ne parle pas du typage fort ou faible. Beaucoup se plaignent du typage fort de Java, non ?
[*]En Java, le typage fort est mal considéré...

Je soupçonne certains de ces gars qui reprochent à un langage d'être fortement typé de ne jamais avoir bossé en équipe sur de très grosses bases de code. Par ailleurs, les gains d'un typage fort et statique en terme de sécurité du code et d'outils IDE (complétion, refactoring) outrepassent largement cette pseudo flexibilité qui sert à se prendre des autogoals.

Désolé de ne pas être plus ouvert. Autant je comprend que pour des scripts vite faits d'import/export de données one-shot c'est agréable de pouvoir jouer sur l'ambiguïté du type des variables, autant pour des grosses choses durables j'estime que ce n'est qu'un filet de sécurité en moins et des chances supplémentaires d'avoir des codes faux qui fonctionnent juste par bol en dév et qui pètent en production.

Enfin voilà, c'est que mon avis, mais moi ça me convient pas.

[tchize_]

Je ne suis pas d'accord avec toi adiguba. En surcharge, il m'arrive régulièrement d'avoir à écrire des méthode qui prennent plusieurs paramètres, chaque paramètre pouvant avoir deux types différents. Je me vois mal remplacer ceci


faitQuelqueChose(Model modele, Personne personne, Region region);
faitQuelqueChose(Model modele, String personne, String region)
faitQuelqueChose(Model modele, Personne personne, String region)
faitQuelqueChose(Model modele, String personne, Region region)

en
faitQuelqueChosePersonneRegion(Model modele, Personne personne, Region region);
faitQuelqueChoseStringString(Model modele, String personne, String region)
faitQuelqueChosePersonneString(Model modele, Personne personne, String region)
faitQuelqueChoseStringRegion(Model modele, String personne, Region region)


Ensuite, les valeur par défaut, c'est bien gentil, mais parfois, la valeur par défaut n'est pas immédiate et nécessite un calcul. Certe on pourrait mettre null, suivi d'un if et dedans calculer. Ce qui ne ferait qu'aboutir à des méthodes plus longue et donc plus difficiles à suivre.

Enfin, il arrive que des méthodes on le même nom car elles ont le même but et un résultat final similaire, mais elles doivent avoir un code différents car les paramètres supplémentaires influencent leur comportement et tout mettre dans une même méthode rendrait la maintenance compliquée et les performances problématiques.

Pour moi, avec une absence de surcharge, les pertes sont sèches. Le code sera pluq dur à lire, l'indépendances des méthodes surchargées n'est plus possible facilement.

[adiGuba]

L'absence de surcharge sur les méthodes est en effet surmontable, mais si on le gère pour les constructeurs, je ne voir pas pourquoi ne pas le faire sur les méthodes.

Les constructeurs sont particuliers car ils ne n’héritent pas. Donc la surcharge est bien plus facile à gérer (c'est limité à la classe courante).


Pour les méthodes il faut gérer la surcharge dans la classe courante, mais également les potentielles redéfinitions et surcharges dans les autres classes de la hierarchie... ce qui est assez complexe à gérer et source de problème potentiel...




@air-dex : il est clairement indiquer qu'ils conserveront le typage fort


a++

[adiGuba]

Je ne suis pas d'accord avec toi adiguba.

Le choix de supprimer la surcharge aura un impact fort sur le langage. Chaque spécificité du langage implique des choix et des solutions différentes dans l'API.
Donc on ne développera pas de la même manière en Ceylon qu'en Java, tout comme on ne développe pas de la même manière en Java qu'en C++...

Dans ton exemple plutôt que de surcharger la méthode je pense qu'on utilisera plutôt une seule et unique version :

Code :

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

faitQuelqueChose(Model modele, Personne personne, Region region);

Qui, couplée avec des méthodes de conversion nous fournira des fonctionnalités similaires :

Code :

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

1
2
3
4
5
6
7
8
9
10
Modele modele = ...
Personne personne = ...
Region region = ...
String name = ...
String regionName = ...
 
faitQuelqueChose(modele, personne, region);
faitQuelqueChose(modele, Personne.from(name), Region.from(regionName));
faitQuelqueChose(modele, personne, Region.from(regionName));
faitQuelqueChose(modele, Personne.from(name), region);

Ensuite, les valeur par défaut, c'est bien gentil, mais parfois, la valeur par défaut n'est pas immédiate et nécessite un calcul. Certe on pourrait mettre null, suivi d'un if et dedans calculer. Ce qui ne ferait qu'aboutir à des méthodes plus longue et donc plus difficiles à suivre.

Ce n'est pas forcément plus court ni plus simple à lire d'avoir plusieurs méthodes qui s'appellent entre-elle...

Enfin, il arrive que des méthodes on le même nom car elles ont le même but et un résultat final similaire, mais elles doivent avoir un code différents car les paramètres supplémentaires influencent leur comportement et tout mettre dans une même méthode rendrait la maintenance compliquée et les performances problématiques.

Tu tombes alors dans mon troisième cas, où il faudra distinguer le nom des méthode...

Pour moi, avec une absence de surcharge, les pertes sont sèches. Le code sera pluq dur à lire, l'indépendances des méthodes surchargées n'est plus possible facilement.

Je n'ai pas dit que la suppression de la surcharge était un meilleur choix, mais simplement que c'était une alternative possible qui apportait certains avantages (et pas que des défauts)


a++

[lunatix]

assez étonnant ce projet :

Gavin king avait annoncé qu'il bossait depuis deux ans sur un projet secret : je ne m'imaginais pas trop un nouveau langage qui n'apporte pas grand chose de neuf. (beaucoup de choses qui viennent de scala, et des autres langages de la jvm). rien d'innovant (comme par exemple intégrer l'ioc ou les tests au langage).

et le fait d'annoncer qu'ils vont aussi refaire tout un SDK c'est assez irréaliste.
Quand on voit les difficultés rencontrées par Scala pour ne refaire que une api de collections valable...

enfin bon, un de plus

[professeur shadoko]

inventaire à la prévert .... donc à mettre dans la catégorie des langages "maquettes": on essaye différents trucs intéressants certes mais ne relevant pas d'une proposition d'un paradigme fort (une "manière de penser").
par ailleurs toujours le même problème: aucun recherche menée sur l'ergonomie de la syntaxe (-"squint test" au minimum -personne ne le fait et c'est dommage! ).

[Philippe Bastiani]

En supprimant les types primitifs et la surcharge, on peut utiliser les paramètres optionnels pour couvrir les 2/3 des cas :

1 / 3 pour moi !

On ne simules plus les paramètres optionnels puisqu'on peut les utiliser directement :

Code :

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

public int indexOf(String str, int fromIndex=0)

Et c'est plus propre au niveau de l'API (une seule méthode à définir et documenter). Et comme il n'y a pas de surcharge c'est bien plus facile à gérer et à faire évoluer...

Oui en effet... on avait celà en C++ d'ailleurs !

On peut se contenter d'une seule et unique méthode pour accepter tout :

Code :

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

public void println(Object obj)

En effet comme il n'y a plus de type primitif, plus besoin de les gérer à part

Ok pour la suppresion des types primitifs... Mais, non le typage faible est pour moi une mauvaise idée:

• Difficile à documenter : ben oui un jour ou l'autre il va bien falloir indiquer à l'utilisateur de ta méthode quel est le domaine couvert par tes paramètres
• Illisible: x tests de parametres - x blocs (ou appels de sous-méthodes) + traitement génériques des cas non couverts par la méthode.
  c.f. l'exemple de @tchize_: OK on s'en sort ! Mais côté lisibilité...
• Non maintenable et difficile à tester: conséquence de l'illisibilité.

Au final:
En supprimant les types primitifs et en l'utilisation des paramètres optionnels on supprime certaines contraintes.
En supprimant la surcharge c'est tout le contraire.

[gl]

C'est d'ailleurs bizarre qu'il ne parle pas du typage fort ou faible. Beaucoup se plaignent du typage fort de Java, non ?

Du typage fort ou du typage statique ?
Autant je peux concevoir que l'on se plaigne du typage statique et que l'on préfère un typage dynamique. Autant concernant un typage fort, j'ai plus de mal. Surtout dans un langage comme Java (et comme bien d'autre langage mainstream) où le typage n'est pas non plus si fort que ça.

C'est d'ailleurs bizarre qu'il ne parle pas du typage fort ou faible. Beaucoup se plaignent du typage fort de Java, non ?

Au contraire, ils précisent bien que le typage statique est à leurs yeux un des plus gros avantage de Java.

Attention à ne pas confondre typage fort/faible et typage statique/dynamique.

[adiGuba]

En supprimant les types primitifs et en l'utilisation des paramètres optionnels on supprime certaines contraintes.
En supprimant la surcharge c'est tout le contraire.

Le problème c'est que les paramètres optionnels et la surcharge ne vont pas très bien ensemble. En C++ le désagrément est limité par la recompilation, mais en Java du fait de la liaison tardive cela peut poser de drôle de problème comme l'impossibilité de faire évoluer la signature de la méthode...

a++

[Philippe Bastiani]

Le problème c'est que les paramètres optionnels et la surcharge ne vont pas très bien ensemble. En C++ le désagrément est limité par la recompilation, mais en Java du fait de la liaison tardive cela peut poser de drôle de problème comme l'impossibilité de faire évoluer la signature de la méthode...
a++

En terme de contraintes, je faisais essentiellement référence à du dev en boîte noire où tu as le contrôle de ton source et de sa compilation.
Mais c'est sûr, surcharge ou pas, dés lors que tu exposes tes APIs, les paramètres optionnels (tout comme les paramètres nommés) sont à proscrire car effectivement le nomage devient une contrainte forte de la signature...

Je me demande comment C# s'en sort !

[adiGuba]

Je me demande comment C# s'en sort !

Il ne s'en sort pas : ils conseillent de ne plus modifier le noms des paramètres des APIs publiques, et de ne pas modifier ni de rajouter des paramètres optionnels à moins de "bidouiller" avec de la surcharge. (j'en ai parlé sur mon blog : Paramètres optionnels/nommés : Danger ?)



a++

[ego]

Encore un nouveau langage qui n'apporte rien de vraiment extraordinaire.
On ferait mieux de se pencher sur les performances, le GC dans des contextes "big big memory", les liens entre couches logicielles, la simplification des archi distribuées,...

Je ne pense pas qu'en travaillant sur un langage on fera avancer énormément les choses, il me semble que c'est plus en travaillant sur les problématiques de conception et d'architectures que l'on a des choses à faire avancer.
Honnêtement, il n'y a pas tant de différences que cela entre le C et Java ou C# et les problèmes que l'on rencontre sur nos applications sont sensiblement les mêmes qu'il y a 20 ans (distribution, persistance, validation d'objet/règles des gestion, cohérence du typage depuis l'IHM jusqu'à la base de données...)

[ego]

1 / 3 pour moi !

Oui en effet... on avait celà en C++ d'ailleurs !

Ok pour la suppresion des types primitifs... Mais, non le typage faible est pour moi une mauvaise idée:

• Difficile à documenter : ben oui un jour ou l'autre il va bien falloir indiquer à l'utilisateur de ta méthode quel est le domaine couvert par tes paramètres
• Illisible: x tests de parametres - x blocs (ou appels de sous-méthodes) + traitement génériques des cas non couverts par la méthode.
  c.f. l'exemple de @tchize_: OK on s'en sort ! Mais côté lisibilité...
• Non maintenable et difficile à tester: conséquence de l'illisibilité.

Au final:
En supprimant les types primitifs et en l'utilisation des paramètres optionnels on supprime certaines contraintes.
En supprimant la surcharge c'est tout le contraire.

Typage faible ? oui ça c'est une idée de m...de (désolé)
On le voit dans mon entreprise sur PHP où du fait du typage faible, on ajoute des assert en début de méthode pour être certain du....typage ! Merci le typage faible.
Et cette idée est une idée pour les fainéants qui ne veulent pas dire les choses clairement mais qui le paye cher lors des tests et éventuellement en production si les tests n'ont pas tout couvert

[tresorunikin]

En fait ca ne serai que du Java DotNet?
les points forts du Java, les meilleurs pratiques du c# et ses nouveautés, et koi de Ceylon????

[Traroth2]

Une expérimentation est toujours intéressante. Si Ceylon permet de dégager de nouvelles idées et de nouvelles manières de programmer efficacement, ça sera positif. Bienvenu à Ceylon !