Discussion :

[thelvin]

Non, c'est pas du tout l'idée.
Le problème avec les types objet, c'est qu'ils ont tout un tas de métadonnées qui prennent de la place et obligent le CPU à faire plein de déréférencement. Bref, Integer comparé à int, c'est lent, ça bouffe de la mémoire et les tableaux sont pas contigus. D'où l'intérêt de int par rapport à Integer.

Mais parfois, on aimerait avoir ce même genre de performances pour d'autres types que juste un entier. Genre un vertex, ou l'exemple de Point2D.
Un peu comme, quand on bosse avec les images, une couleur RGBA est représentée par un int pour raisons de performances... Alors que ce serait bien pratique si c'était sous forme de red, green, blue, alpha ou tout en même temps. Mais avec des classes ce serait bien trop lourd.

[bouye]

Ok donc retour à la struct ou à l'union... Pas vraiment convaincu que le "slogan publicitaire" qu'il aient choisi soient le bon dans ce cas.
Ce qui m'ennuie en tant que programmeur ce n'est pas tant que les données de BigInteger ou de Color ou de mes classes ne soient pas contiguës mais plutôt le fait que la syntaxe objet ajoute de la lourdeur là où il n'y a pas besoin d'en avoir. Après bien sur c'est de leur faute d'avoir repoussé la possibilité de faire des opération sur les Big* plusieurs fois d'affilée...

Après bien sur je ne cracherai pas sur une amélioration de performances du à un "stockage de données contiguë" coté client,mais c'est plutôt coté serveur que ça prend tout son sens que ça sera vraiment apprécié et donc ça n'a pas vraiment d’intérêt de faire porter les exemples sur Point2D ou Color.
Ca peut avoir son intérêt coté mobile/smart devices, mais encore faudrait-il que Sun et Google s'entendent pour qu'Android passe le pas vers cette hypothétique future version et on sait tous que ce n'est pas près d'arriver. Ça restera confidentiel sur les autres plateformes tant qu'Oracle n'arrivera pas à faire que Java soit plus souvent utilisé sur iOs (et comme ils ont préféré se désister sur bébé sur la communauté, ça risque de prendre du temps).

[23JFK]

ça ne serait pas plus simple d'introduire la surcharge d'opérateurs comme en C++ , les machines modernes étant suffisamment puissantes pour "cacher" les lourdeurs de la gestion des objets ?

[atha2]

Ca peut avoir son intérêt coté mobile/smart devices, mais encore faudrait-il que Sun et Google s'entendent pour qu'Android passe le pas vers cette hypothétique future version et on sait tous que ce n'est pas près d'arriver

Sait-on jamais, je pensais la même chose et Java 7 est arrivé sur android (quand sort Java 8 mais c'est déjà ça). Au vu des procès entre Oracle et Google, j'avais fait une croix dessus. A priori une syntaxe n'est pas brevetable (les procès portait surtout sur les API et 5 lignes de code basiques). A voir si le comportement lié à une syntaxe peut être breveté.

Pour en revenir au sujet, je sais que ce projet n'est qu'à ses balbutiements mais, au lieu d'avoir deux mots-clés pour créer une "value type" (ou "value class"):

Code :

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

final __ByValue class Point { ...

Ils devraient plutôt faire usage du mot-clé "struct". Bien sur sa signification n'aura pas la même chose qu'en C ou C++, un peu comme l'a fait C# pour sa version du struct.

le __ByValue et le __MakeValue ne sont que des placeholder pour un mot-clé qui reste à définir. J'aime bien struct Pour le __MakeValue, les propositions (non exhaustives) sont :

Code :

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

1
2
3
4
 
decimal salary = new decimal(100, 2);
decimal salary = decimal(100, 2);
decimal salary = (100, 2);

Puis pour l'instanciation d'une "value type", ne pas utiliser le mot-clé "new" :

Code :

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

1
2
3
decimal salary1; // pas d'argument, constructeur par défaut
decimal salary2(); // ou bien
decimal salary3(100, 2);

Un peu comme en C++, sans le risque de confusion avec la déclaration de prototype de fonction.

La première proposition n'est pas possible en java, sinon on n'a plus la distinction entre un pointeur et une valeur (en C++ on déclare un pointeur decimal * salary(0); ). Pour la deuxième (qui en C++ est une déclaration de fonction ) et la troisième, le problème c'est que, par exemple, pour le retour anonyme et il faudra faire comme en C++ cad :

Code :

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

return decimal(100, 2)

Et là on se retrouve avec l'impression d'appeler une fonction (d’ailleurs un analyseur syntaxique n'est pas capable de faire la différence) et non de créer un objet (en JS c'est là même chose, mais c'est une autre philosophie ). Même si j'adore le C++, je n'ai pas envie de me retrouver avec la complexité de la syntaxe du C++ en Java. A mon sens, la syntaxe de Java doit rester compréhensible sans le contexte (localisation, symbole), rester simple.

[foetus]

Ok donc retour à la struct ou à l'union...

Pas forcèment

Comme l'a dit 23JFK, en C++, il y a la surcharge des opérateurs (+, -, -, +=, ==, /=, ...), et on peut faire des constructeurs pour les conversions implicites.

Et toujours en C++, il y a les opérateurs pour transformer une classe vers un POD (int float, ...) ou une autre classe.

Ainsi, avec le jeux des conversions, la JVM pourrait stocker des types point2D avec juste un entier, et le récupérer en type Point2D.
Ou que la classe BigInteger se comporte comme un type primitif.

Mais, le seul truc c'est que la surcharge des opérateurs n'est pas triviale et demande de la réflexion. Surtout que l'on peut "casser" la langage

[Gugelhupf]

La surcharge des opérateurs ne serait utile qu'avec des objets tels que String, BigInteger & BigDecimal...
Ils auraient pu ajouter la surcharge d'opérateur il y a très longtemps je pense, mais Java est un langage strict, et ne laisse pas les développeurs faire n'importe quoi, comme additionner deux animaux oiseau et chat (cela n'a pas de sens même si on peut le faire en C++ et C#, cf ce qu'a dit thelvin).

La première proposition n'est pas possible en java, sinon on n'a plus la distinction entre un pointeur et une valeur (en C++ on déclare un pointeur decimal * salary(0); ). Pour la deuxième (qui en C++ est une déclaration de fonction ) et la troisième, le problème c'est que, par exemple, pour le retour anonyme et il faudra faire comme en C++ cad :

Code :

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

return decimal(100, 2)

Et là on se retrouve avec l'impression d'appeler une fonction (d’ailleurs un analyseur syntaxique n'est pas capable de faire la différence) et non de créer un objet (en JS c'est là même chose, mais c'est une autre philosophie ). Même si j'adore le C++, je n'ai pas envie de me retrouver avec la complexité de la syntaxe du C++ en Java. A mon sens, la syntaxe de Java doit rester compréhensible sans le contexte (localisation, symbole), rester simple.

Oui il peut y avoir risque de confusion pour la première solution, mais c'est comme confondre une interface avec une classe, cela s'utilise de la même manière. La première solution ne me parait pas absurde dans le sens où il n'y a pas de distinction entre la déclaration d'une variable primitive et un objet :

Code :

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

1
2
int var;
Object ob;

Pour la 2ème et 3ème je suis d'accord, et j'ai trouvé une alternative meilleure sur internet, au lieu que ce soit l'objet qui prenne les paramètres, c'est le type qui pourrait le prendre :

Code :

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

1
2
3
decimal d1;
decimal(100, 2) d2;
return decimal(100, 2);

Et le tour est joué

[la.lune]

Pour la deuxième (qui en C++ est une déclaration de fonction ) et la troisième, le problème c'est que, par exemple, pour le retour anonyme et il faudra faire comme en C++ cad :

Code :

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

return decimal(100, 2)

Non pas forcement à quoi ça sert l’inférence de type mais la fonction possède un type de retour non? Il va obligatoirement me refuser de retourner quelque chose qui ne correspond pas au type c'est simple je je retourne (100,2), quand même il sait vérifier que le type de retour est un décimal et qu'il existe un constructeur qui prend deux paramètres dont deux entier, de la même manière qu'il ne refuse pas de faire decimal salary=(100,3) il va accepter les deux valeur entre parenthèses et tout est réglé. La JVM sait faire de l’inférence de type depuis l'entrée des generic et maintenant avec les lambda il sait bien reconnaître les types des paramètres des fonction.

La bonne chose que j'ai aimé quand j'ai vu le document c'est le fait de ne pas être obligé d'utiliser la fonction equals pour comparer, certes on la crée pour la définir mais on peut utiliser l'operateur == au lieu de équals. Moi si on m'a dit de proposer j'aurais proposé à ce qu'on nous donne la possibilité de ne pas être toujours obligé de définir un constructeur, et éxiger un constructeur primaire, un peu comme en C# 6 mais pas forcement la même chose car ici ça doit être le critère de reconnaissance d'un Value Type. Tout se fait automatiquement après, et vu qu'ici le plus important c'est simplifier la manipulation des valeurs il faut toujours simplifier les choses. Voila comment je vois que les choses devraient être:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
final class Point(int x, int y){ //Le reste se fait automatiquement x et x sont public
private int c;//Si je veux avoir une valeur privé
boolean equals(Point p){
return this.x==p.x&&this.y==p.y}
public static Point manipuler(){
int a; int b;
//traitement
return (a,b); //inférence de type
}
public static void maFunction(Point p, boolean b, double b){
//traitement
}
} 
final class MaClass(char a, double f, boolean b){
}//ça peut suffir déjà, si c'est pour manipuler un value Type de maClass

Manipulation;

Code Java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Point p1=(2,4),p2=(5,6),p3=(2,4);
boolean b=p1==p3;
boolean b2=p1==(2,4);//inférence de type
boolean b3=p1.equals((2,3));//inférence de type
/*ERROR*/ boolean b2=(2,4)==p1;// Possible de faire de l’inférence de type mais en fait il faut qu'on sache que c'est la fonction equals qui est appelé 
//alors ça sera moche qu'en compilation il va transformer (2,4)==p1 en p1.equals((2,4)) ou tout simplement il va créer une nouvelle Value Type
/*ERROR*/ boolean b4=(2,4)==(2,4)// pas de base pour une inférence de type
Point a=Point.manipuler();
//Si après import statc Point
Point a=manipuler();
maFunction((3,5),true,2.4);//inference de type
//On peut faire du casting
Point2D p=(Point2D)(Point)(2,3);
//Je ne peux pas faire
/*ERROR*/ Point2D p=(Point2D)(2,3);//ERROR il ne connait pas (2,3) et s'il existe déjà un contructeur pas besoin de casting alors
MaClass M=('d',4.5,true);

Si quelqu'un sait comment soumettre une proposition j'allais envoyer ça, qu'en dites vous de cette proposition?

[la.lune]

Code :

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

return decimal(100, 2);

Qui me dit que decimal n'est pas une fonction qui prend deux entier?

Code :

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

1
2
decimal d1;
decimal(100, 2) d2;

Et tu fera comment pour plusieurs variables à la fois? tu va faire

Code :

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

1
2
 
decimal(100, 2) d1, (100,4) d2, (13,4)d4

[thelvin]

Bon tout le monde, concernant BigInteger, 'faudra peut-être se rappeler que c'est un type de taille variable, et donc pas éligible à ce truc. Qui d'ailleurs n'a rien à voir avec la possibilité ou non d'autoriser à définir des opérateurs pour les objets.

La JVM sait faire de l’inférence de type depuis l'entrée des generic

Non, le compilateur sait le faire.

Let vu qu'ici le plus important c'est simplifier la manipulation des valeurs il faut toujours simplifier les choses.

Ici l'idée est de simplifier les choses pour la machine, pas pour le programmeur.
Évidemment ce n'est pas une raison pour compliquer la vie du programmeur quand ça peut être évité, mais le fait de définir des types à la manipulation aussi rapide que les types primitifs, n'implique pas de vouloir tout faire différemment d'avec les types objets. Les raccourcis c'est facile quand on pense qu'à son propre but et pas au but général.

Qui me dit que decimal n'est pas une fonction qui prend deux entier?

Le fait qu'il n'y ait pas de fonction en Java.

Et tu sauras que ce n'est pas une méthode qui prend deux entiers, au fait qu'il n'y a pas de méthode nommées "decimal" et qui prend deux entiers.
Dans le cas où justement, il y en a une, on pourrait estimer que c'était une mauvaise idée d'en avoir une dans une classe qui importe le type valeur "decimal", et que ce soit un cas où le pseudoconstructeur est caché par la méthode. Ou carrément une erreur de compilation pour cause de nommage ambigu.
... Mais effectivement, ça me semble une mauvaise idée, à moi. Sans doute nécessité d'une nouvelle syntaxe de construction, semblable au "new" mais laissant paraître qu'on ne construit pas un objet mais une valeur.

Et tu fera comment pour plusieurs variables à la fois? tu va faire

+1, et aussi concernant la définition de tableaux.
D'ailleurs concernant la définition de tableaux, on se rend compte qu'une valeur par défaut des types valeurs doit quasi-obligatoirement être prévue, et facilement calculable.

Moi si quelqu'un sait comment soumettre une proposition j'allais envoyer ça, qu'en dites vous?

Je suggère d'améliorer ta nomenclature, et de méditer un peu sur les buts recherchés et non recherchés. ... Mais j'ai des doutes sur le fait que ce genre-là de questions les intéressent encore de toute façon.

[la.lune]

Non, le compilateur sait le faire.

Merci pour la remarque.

mais le fait de définir des types à la manipulation aussi rapide que les types primitifs, n'implique pas de vouloir tout faire différemment d'avec les types objets. Les raccourcis c'est facile quand on pense qu'à son propre but et pas au but général.

Mais d'après le document les Values Types ne sont pas des objets, pas d'instanciation pas d'appel de new ni implicite ni explicite. Alors vaut mieux rompre la relation pour de bon, il faut qu'on voit les choses différemment.

Le fait qu'il n'y ait pas de fonction en Java.

C'est par abus de langage mais les import static font la même chose, donc si je fais un import static d'une méthode moi qui va analyser le code je ne saurais pas si c'était un value type ou une méthode static.

Et tu sauras que ce n'est pas une méthode qui prend deux entiers, au fait qu'il n'y a pas de méthode nommées "decimal" et qui prend deux entiers.

C'est ça le problème, je peux avoir à manipuler et retourner un objet de type décimal dans une autre classe il suffit qu'il existe une autre méthode nommé decimal dans la classe pour que ça ne compile pas, car par forcement que la méthode décimal de la classe encoure retourne un décimal, encore des confusions devant le développeur qui ne sait pas si c'était une méthode ou un Value Type. Après quelque temps il revient sur son code il se perd.

Mais effectivement, ça me semble une mauvaise idée, à moi. Sans doute nécessité d'une nouvelle syntaxe de construction, semblable au "new" mais laissant paraître qu'on ne construit pas un objet mais une valeur.

Je suggère d'améliorer ta nomenclature, et de méditer un peu sur les buts recherchés et non recherchés. ...

Bon j'ai juste fais une erreur pour maClass en fait c'est MaClass et on ne change rien côté nomenclature avec Java. Pour les buts recherchés, en plus du fait que c'est la simplification pour la machine, mais on doit aussi vivre ce que la machine fait comme lorsqu'on manipule des valeur primitives, je suis totalement contre le fait de créer un tableau de Vlues Type et au milieu on doit répéter des appel construction comme des objet, déjà c'est moche pour les tableau d'objets. Il faut exploiter la capacité de l’inférence de type.

Code Java :

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

1
2
3
4
5
6
7
//Par inférence de type
Point pts[]=new Point[]{(2,5),(3,6),(5,7),(9,10),(12,34),(17,20),(7,12)};
Stream.of(pts).forEach(out::println)//J'appel la méthode toString de chaque Point
//Inférence de type génériques
List<Point> points=Arrays.asList((2,5),(3,6),(5,7),(9,10),(12,34),(17,20),(7,12));
points.add((2,4));
points.stream().forEach(p->deplacer(2,2));

Imaginez si j'aurais à répéter Point à chaque fois?

Ainsi, parmi les buts recherchés c'est un gain en productivité, plus de lisibilité et plus de précision pour des nouveaux joujoux dans le programme facilement reconnaissables, pas de confusion, et si ça se fait que qu'ils seront 100% organisé de façon contiguë dans la mémoire alors ça ressemble normalement à la manière dont ils seront stockés.

Il ne faut pas oublier que ce truc là peut faire un boom en Java si ça contribue côté performance et consommation de la mémoire, seulement comme c'est dit ils sont final pas d'héritage pour les Values Type concrètes. Mais là on va garder les objets si le but est orienté fonctionnalité et non de simple valeur, ainsi pour les besoins aussi d'extensibilités et de reutilisabilités qui sont offert par le polymorphisme, héritage... on garde bien la POO classique.
Il y a plusieurs choses intéressantes dans ce que je viens de dire.

Mais j'ai des doutes sur le fait que ce genre-là de questions les intéressent encore de toute façon.

Qui ne tente rien ne gagne rien, c'est une proposition par tant autre à eux de juger. Déjà je peux donner toutes les instructions que le compilateur va agir pour chaque manipulation d'un value type que j'ai exposé, en se basant des mots clés de base proposés dans le document.

[atha2]

La première proposition n'est pas possible en java, sinon on n'a plus la distinction entre un pointeur et une valeur (en C++ on déclare un pointeur decimal * salary(0); ). Pour la deuxième (qui en C++ est une déclaration de fonction ) et la troisième, le problème c'est que, par exemple, pour le retour anonyme et il faudra faire comme en C++ cad :

Code :

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

return decimal(100, 2)

Et là on se retrouve avec l'impression d'appeler une fonction (d’ailleurs un analyseur syntaxique n'est pas capable de faire la différence) et non de créer un objet (en JS c'est là même chose, mais c'est une autre philosophie ). Même si j'adore le C++, je n'ai pas envie de me retrouver avec la complexité de la syntaxe du C++ en Java. A mon sens, la syntaxe de Java doit rester compréhensible sans le contexte (localisation, symbole), rester simple.

Oui il peut y avoir risque de confusion pour la première solution, mais c'est comme confondre une interface avec une classe, cela s'utilise de la même manière.

La différence c'est qu'on s'en fout de savoir si on manipule via une interface ou une classe. Dans les 2 cas c'est un objet qu'on manipule. Là confondre un appel de méthode avec la création d'un type value, ce n'est pas la même chose.

Pour la deuxième (qui en C++ est une déclaration de fonction ) et la troisième, le problème c'est que, par exemple, pour le retour anonyme et il faudra faire comme en C++ cad :

Code :

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

return decimal(100, 2)

Non pas forcement à quoi ça sert l’inférence de type mais la fonction possède un type de retour non? Il va obligatoirement me refuser de retourner quelque chose qui ne correspond pas au type c'est simple je je retourne (100,2), quand même il sait vérifier que le type de retour est un décimal et qu'il existe un constructeur qui prend deux paramètres dont deux entier, de la même manière qu'il ne refuse pas de faire decimal salary=(100,3) il va accepter les deux valeur entre parenthèses et tout est réglé. La JVM sait faire de l’inférence de type depuis l'entrée des generic et maintenant avec les lambda il sait bien reconnaître les types des paramètres des fonction.

Le problème n'est pas que le compilateur sache faire la différence (il le saura tôt ou tard), le problème est qu'un développeur ne peut pas savoir au premier coup d’œil ce qu'il lit. Par exemple sur un tutoriel, on n'a pas toujours tout le contexte du code.

La première solution ne me parait pas absurde dans le sens où il n'y a pas de distinction entre la déclaration d'une variable primitive et un objet :

Code :

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

1
2
int var;
Object ob;

Elle est absurde parce que si on peut écrire

Code :

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

1
2
3
 
int a;//intialisation à 0 par défaut
int a = 2;

sans que ce soit trop génant (0 est créé sans que ce soit utile), pour par exemple une classe byValue Matrix10x10 :

Code :

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

1
2
3
 
Matrix10x10 mat;//création d'un tableau de 100 entier initialisés à 0
mat = new Matrix10x10(1, 2 ...., 100)

Et là on se retrouve avec un gaspillage de mémoire
Alors que sans le byValue, à la première ligne on aurait juste alloué de la mémoire pour stocker un pointeur. C'est sur ce point que ta syntaxe pose problème. Avec la même syntaxe, on se retrouve à faire 2 choses différences.

[la.lune]

Les gens qui ont de quoi à commenter ou à proposer quelque chose qui vont renforcer le concept ils n'ont qu'a le faire par ici https://news.ycombinator.com/item?id=7685083, Personnellement je n'ai rien à dire sur la manière dont au fond de la JVM ça va se passer, mais j'ai juste eu cette idée sur la manipulation. Mais là je dois bien réfléchir et écouter les avis des autres avant d'aller dire du n'importe quoi.

[thelvin]

Elle est absurde parce que si on peut écrire

Code :

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

1
2
3
 
int a;//intialisation à 0 par défaut
int a = 2;

sans que ce soit trop génant (0 est créé sans que ce soit utile), pour par exemple une classe byValue Matrix10x10 :

Code :

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

1
2
3
 
Matrix10x10 mat;//création d'un tableau de 100 entier initialisés à 0
mat = new Matrix10x10(1, 2 ...., 100)

Et là on se retrouve avec un gaspillage de mémoire
Alors que sans le byValue, à la première ligne on aurait juste alloué de la mémoire pour stocker un pointeur. C'est sur ce point que ta syntaxe pose problème. Avec la même syntaxe, on se retrouve à faire 2 choses différences.

Je doute que cela soit possible en Java de toute façon. Les champs sont d'abord créés avec une valeur par défaut, puis ensuite on leur assigne une valeur, dans l'initialisation, le constructeur ou ce qu'on veut.
Cela va avec le principe de sûreté de Java et le fait que même si on accède à un champ avant que le champ n'ait subi toutes les initialisations, il a quand même une valeur connue, non aléatoire, même si c'est pas évident du point de vue du programmeur.
D'ailleurs ça devrait être embarrassant quand il s'agira de mettre en œuvre une "valeur par défaut" des valueTypes, comment la définir, et comment la mettre en œuvre au chargement d'une classe et à l'allocation d'un objet.

En tout cas ce sera en effet un problème avec des valueTypes très grands. Tout comme les passer en paramètre.

[la.lune]

D'ailleurs ça devrait être embarrassant quand il s'agira de mettre en œuvre une "valeur par défaut" des valueTypes, comment la définir, et comment la mettre en œuvre au chargement d'une classe et à l'allocation d'un objet.

Pas de possibilité de fournir une valeur par défaut avec l'intention de modifier des champs encours de route, c'est fini si tu donnes des valeur par défaut! Définir des valeurs par défaut pour un value type c'est définir tout simplement une constante Value Type, tous les objets de même type auront tous les même valeur non modifiables. Tous les champs sont obligatoirement final, leurs initialisation passe par le constructeur. Assigner une valeur une variable de type Value Type c'est détruire l'ancien et créer un nouveau. Il est dit dans le document

Can a value class contain a non-final field? No.

Pas de champ non final. Ainsi on voit comme si il n y a pas à manipuler et détruire les variables internes, déjà l'exemple que j'ai donné comme si on déplace, alors ce genre de fonction dont le but est de modifier le contenu doivent être static comme vous voyez cet exemple fourni

Code :

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

1
2
3
4
5
6
7
8
static Point origin = __MakeValue(0, 0);
static Point displace(Point p, int dx, int dy) {
    if (dx == 0 && dy == 0)
      return p;
    Point p2 = __MakeValue(p.x + dx, p.y + dy);
    assert(!p.equals(p2));
    return p2;
}

Et là je répond à @atha2 pour son exemple d'une matrice comme tous les données seront crée et initialisé par zéro par une simple déclaration. Ce n'est pas possible car l'initialisation doit se faire en appelant un constructeur, on a la notion de référence même si ça ne marche pas comme des objets. Sinon comment créer des méthodes qui vont manipuler des matrices et autre vu qu'on a pas de pointeur en Java.

Code :

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

1
2
3
public static  Matrix10x10 calcule(Matrix10x10 m1,Matrix10x10 m2){
 
}

Tu sais @atha si ce que tu dis est vrai, une simple appellation de cette méthode calcule exigera une copie de tous les éléments de m1, et m2, et une fois retourner quelque chose ça ne va pas retourner la matrice qui est crée à l'intérieur de la fonction et utilisé pour retourner mais encore une copie de toute la matrice résultant
Jamais une chose pareil aura lieu en Java.

Moi ce que j'ai pensé aussi pour des values types d'après ce que j'ai pensé que ça devrait être c'est lorsqu'on veut manipuler un Value Type d'une seule dimension, je pense que ça doit avoir le même comportement qu'un Wrapper ce qui reviendrait à pouvoir enlever les parenthèses dans le cas précédant que j'ai exposé sinon ça va créer un grand problème de confusion, car les exemples suivants sont correctes en java,

Code :

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

1
2
3
4
5
6
7
8
public static Integer fInt(){
    return 3;
    }
public static Integer fInt2(){
return (3);
}
Integer []tabi = new Integer[]{(2),(4),(5),(7)};
Integer []tabi2 = new Integer[]{2,4,5,7};

Déjà ça revient sur le fait que le compilateur reconnait ce qu'il faut, il suffit que je change par exemple pour fInt() le 3 en 3.0 pour que ça ne compile pas.
Alors ça serait jolie si par exemple je crée une value type comme ça

Code :

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

final class Valeur(int a){}

Je pusse faire comme ça:

Code :

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

Valeur []tabi2 = new Valeur[]{2,4,5,7};

Par contre cette proposition je crois que ça va les intéresser

[thelvin]

Pas de possibilité de fournir une valeur par défaut avec l'intention de modifier des champs encours de route, c'est fini si tu donnes des valeur par défaut! Définir des valeurs par défaut pour un value type c'est définir tout simplement une constante Value Type, tous les objets de même type auront tous les même valeur non modifiables. Tous les champs sont obligatoirement final, leurs initialisation passe par le constructeur. Assigner une valeur une variable de type Value Type c'est détruire l'ancien et créer un nouveau. Il est dit dans le document

Can a value class contain a non-final field? No.

Pas de champ non final.

Tu t'emmêles carrément .

Pas de champ non-final ça veut dire que c'est un type immutable. String aussi est un type immutable, es-tu en train de dire qu'on peut pas faire :

Code :

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

1
2
String s = "bonjour";
s = "le monde !";

?

(D'ailleurs les types primitifs aussi sont immutables, au fond. Ça a juste pas de sens pour eux de se poser la question. 4 c'est 4 on va pas le modifier.)

[la.lune]

String aussi est un type immutable, es-tu en train de dire qu'on peut pas faire :

Code :

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

1
2
String s = "bonjour";
s = "le monde !";

?

Mais là tu n'a pas donné de valeur par défaut pour un String tu as une variable de type String que tu manipule, quel est le String par défaut? Moi quand je parle de valeur qu'on ne peut pas fournir de valeur par défaut, je parle des variables "d'instance" car ils sont finales mais pas qu'une variable donnée une fois le type crée on ne peut pas le modifier.
De la même manière que tu ne peux pas faire

Code :

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

1
2
final String s = "bonjour"; 
s = "le monde !";

Ainsi, si tu fourni de valeur par défaut au champs d'un Type Value là tu viens juste de définir une constante type.

[thelvin]

Mais là tu n'a pas donné de valeur par défaut pour un String tu as une variable de type String que tu manipule, quel est le String par défaut?

null peut-être ? Tu sais, comme tous les types objet ?

Moi quand je parle de valeur qu'on ne peut pas fournir de valeur par défaut, je parle des variables "d'instance" car ils sont finales mais pas qu'une variable donnée une fois type crée on ne peut pas le modifier.

Certes. Mais vu que moi, ce n'est pas de ça que je parlais, je vois pas bien pourquoi tu as rebondi dessus.

[la.lune]

null peut-être ? Tu sais, comme tous les types objet ?

Mais le null c'est la variable de type string qui peut avoir la valeur null, mais le tableau de char que possède String n'a jamais de valeur par défaut, la référence oui pointe vers null, mais on ne dit pas cela de valeur par défaut, on dit tout simplement de référence qui ne pointe sur aucune instance, sinon si le null que pointe la référence sans instance était une valeur par défaut valide déjà existante, alors on devait pas pouvoir modifier une valeur final qui vient d'être déclaré. Car l'instruction suivante est une erreur de compilation

Code :

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

1
2
final String s=null;
         s="shdhshd";

Je ne peux plus aussi faire

Code :

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

1
2
final String s ;
      boolean b= s==null;

il va me dire que s n'est pas initialisé.

Certes. Mais vu que moi, ce n'est pas de ça que je parlais, je vois pas bien pourquoi tu as rebondi dessus

C'est en fait ce que j'ai compris quand tu as posée la question,

D'ailleurs ça devrait être embarrassant quand il s'agira de mettre en œuvre une "valeur par défaut" des valueTypes, comment la définir, et comment la mettre en œuvre au chargement d'une classe et à l'allocation d'un objet.

Alors personne n'a répondu j'ai dis ce que je pensais mais il faut le prendre simple aussi dans le cadre de discussion Je peux parfois me tromper ou dire du n'importe quoi, mais ça reste que tout entre dans la discussion.

[thelvin]

Tu t'embrouilles vraiment à mort. Sans rire, il va falloir te mettre un peu au point avant de proposer des trucs pour la définition du langage Java -_-°.

Donc, oui null est la valeur par défaut du type String et de tous les types objets, c'est comme ça et on dit ça que ça te plaise ou non. Oui c'est aussi le fait de ne pointer vers aucun objet, donc la valeur par défaut du type String c'est de ne pas pointer vers un objet. Et alors ?
Chose impossible avec les types de base et valueTypes, d'où le problème original que j'évoquais, comment on leur donne une valeur par défaut puisque c'est pas null.

Ensuite et c'est là que les choses se compliquent, figure-toi que si, le tableau de char d'une String, tout comme toutes les variables membres, commence d'abord par avoir une valeur par défaut, null. Ensuite il est assigné une fois et une seule, comme imposé par son status de final, dans le constructeur.
Comme cette variable est final, le langage Java interdit de la lire en connaissance de cause avant qu'elle ait été assignée. Comme elle est aussi private, et que this n'est pas exposé dans le constructeur de String, il est très difficile de lire cette variable avant son assignation sans connaissance de cause. Difficile mais possible en théorie, en jouant sur les threads.
Le langage Java rend très compliqué de le voir, et on va pas s'en plaindre, on a pas envie de savoir qu'une variable final porte deux valeurs dans sa vie au lieu d'une. Mais le runtime qui applique le bytecode de la classe, lui, il est parfaitement au courant. Il doit d'abord allouer l'espace de l'objet et initialiser cet espace à des valeurs sûres. Ce qui, pour le tableau de chars, correspond à null. Sa valeur définitive arrivera plus tard, pendant le constructeur.
Et bien que cela n'ait rien à voir avec être final ou pas, les valueTypes, tout comme un tableau de char, devront être initialisés à des valeurs par défaut. La question que je me pose, c'est : comment on définira leur valeur par défaut ? C'est pas que ce soit si difficile d'imaginer comment le faire dans le langage, mais ça devrait être différent pour chaque valueType. La JVM chargée de charger la classe, va donc devoir savoir, quand une classe contient une variable de type valueType, comment lui définir une valeur par défaut. Et là ça devient contradictoire avec les principes passés, d'une manière ou d'une autre.

[adiGuba]

Salut,

Chose impossible avec les types de base et valueTypes, d'où le problème original que j'évoquais, comment on leur donne une valeur par défaut puisque c'est pas null.

Ce problème est évoqué dans la proposition, à la fin de la section "General approach: usage" :

A fourth aspect of primitives is that, although they do not have values that correspond to the null reference, they do have default values, generally some sort of zero. This default value shows up in the initial contents of uninitialized fields and array elements. It is therefore necessary to specify a default value for each value type. The simplest default composite value is the one which which is recursively default in all of its subfields. Given that predefined default values are a fixture in Java, this convention does not appear harmful, so we will adopt it.

As a result, the author of methods in a value type definition will need provide behavior to default (all-zero-bits) values, even if the constructors never create them, since they can be observed in some uninitialized variables. It is likely that we will either forbid no-argument constructors or require them to produce default values, to avoid “duelling defaults”.

a++