Tant qu'on y est, tu veux pas non plus forcer l'utliisateur a taper son nombre dans une locale donnee?
Nan, parce que 2,001 ca veut dire 2 choses radicalement differentes de differents cotes de l'atlantique.
Ou pousser le concept jusqu'au bout, a savoir interdire addition int/float ou autres joyeusetes, comme le fait caml avec ses operateur entiers/flottants?
Bref, colonne typee string ou int, tu prends une string en entree dans les deux cas de toutes facons.
Juste que dans un cas, tu peux pas assurer l'existence de l'operation jusqu'a l'evaluation, mais ca change pas grand chose conceptuellement.
Note que je viens de tester dans excel, et c'est bien precise que c'est un format d'affichage, pas un type de donnees.
Ca donne des indices au tableur pour formatter la valeur suivant certaines conventions, mais le type est toujours inferee automatiquement.
Tu dis n'importe quoi : dans 2.45E, si je ne m'abuse, le type de donnee apparait : ce sont des euros (donc des nombres a virgule ; et en plus on sait qu'on ne va pas les additionner avec des dollars sans effectuer de conversion). Ca sert a rien d'ecrire la meme chose en beaucoup plus long avec des termes cabalistiques juste en dessous.
Ah bah si ca sert a rien, pourquoi tu veux forcer l'utilisateur a faire un String.parseInt(cellule) alors?
Parce que pour autant que je sache, l'operateur + sur une classe utilisateur est pas trivial (meme si ici, ca parait assez evident).
Bien la preuve que la notion de cast explicite obligatoire n'a rien de naturel: tu vois un 2, c'est le nombre 2, qu'il soit suiv par un symbole euro ou entoure de chaine (que tu ne vois meme pas dans le cas du tableur).
J'ai surtout pas dit le contraire. Apres, si tu manges ta viande avec une cuillere, ce n'est pas de la faute du tiroir : la faute en incombe a celui qui a range les couverts et a celui qui a pris une cuillere sans verifier que ce n'etait pas une fourchette.
Et? La viande, ca se mange tres bien avec une cuillere. C'est un peu moins pratique, mais ca marche.
Un peu comme parser un entier dans une string: c'est un peu plus chiant, mais c'est faisable.
si on veut simplifier l'experience utilisateur tout en la fiabilisant, le typage des donnees il doit etre fait.
Simplifier l'experience utilisateur?
Tu vas simplifier quoi en disant a l'utilisateur que 2+"2" est illegal mais que ooo veut bien convertir en 2+2?
L'utilisateur il est pas developpeur, c'est une notion qui lui passe au dessus du cigare et il s'en tamponne.
il voit un 2 dans une cellule et un autre 2 dans un autre cellule, additione les moi.
Il est capable de comprendre que 2 + toto n'a pas de sens par contre (et ca tombe bien, il s'etonnera pas de voir 2toto ou "erreur" dans la cellule ou il a demande ca).
Bref, le cast implicite sans emmerder l'utilisateur, ca fait bel et bien partie de la problematique du tableur.
[^] # Re: Dans ce cas le probleme est...
Posté par thedude . En réponse au journal Oui je sais, on est pas Vendredi. Évalué à 3.
Nan, parce que 2,001 ca veut dire 2 choses radicalement differentes de differents cotes de l'atlantique.
Ou pousser le concept jusqu'au bout, a savoir interdire addition int/float ou autres joyeusetes, comme le fait caml avec ses operateur entiers/flottants?
Bref, colonne typee string ou int, tu prends une string en entree dans les deux cas de toutes facons.
Juste que dans un cas, tu peux pas assurer l'existence de l'operation jusqu'a l'evaluation, mais ca change pas grand chose conceptuellement.
Note que je viens de tester dans excel, et c'est bien precise que c'est un format d'affichage, pas un type de donnees.
Ca donne des indices au tableur pour formatter la valeur suivant certaines conventions, mais le type est toujours inferee automatiquement.
Tu dis n'importe quoi : dans 2.45E, si je ne m'abuse, le type de donnee apparait : ce sont des euros (donc des nombres a virgule ; et en plus on sait qu'on ne va pas les additionner avec des dollars sans effectuer de conversion). Ca sert a rien d'ecrire la meme chose en beaucoup plus long avec des termes cabalistiques juste en dessous.
Ah bah si ca sert a rien, pourquoi tu veux forcer l'utilisateur a faire un String.parseInt(cellule) alors?
Parce que pour autant que je sache, l'operateur + sur une classe utilisateur est pas trivial (meme si ici, ca parait assez evident).
Bien la preuve que la notion de cast explicite obligatoire n'a rien de naturel: tu vois un 2, c'est le nombre 2, qu'il soit suiv par un symbole euro ou entoure de chaine (que tu ne vois meme pas dans le cas du tableur).
J'ai surtout pas dit le contraire. Apres, si tu manges ta viande avec une cuillere, ce n'est pas de la faute du tiroir : la faute en incombe a celui qui a range les couverts et a celui qui a pris une cuillere sans verifier que ce n'etait pas une fourchette.
Et? La viande, ca se mange tres bien avec une cuillere. C'est un peu moins pratique, mais ca marche.
Un peu comme parser un entier dans une string: c'est un peu plus chiant, mais c'est faisable.
si on veut simplifier l'experience utilisateur tout en la fiabilisant, le typage des donnees il doit etre fait.
Simplifier l'experience utilisateur?
Tu vas simplifier quoi en disant a l'utilisateur que 2+"2" est illegal mais que ooo veut bien convertir en 2+2?
L'utilisateur il est pas developpeur, c'est une notion qui lui passe au dessus du cigare et il s'en tamponne.
il voit un 2 dans une cellule et un autre 2 dans un autre cellule, additione les moi.
Il est capable de comprendre que 2 + toto n'a pas de sens par contre (et ca tombe bien, il s'etonnera pas de voir 2toto ou "erreur" dans la cellule ou il a demande ca).
Bref, le cast implicite sans emmerder l'utilisateur, ca fait bel et bien partie de la problematique du tableur.