Il m'aura fallu quand m=EAme juste quelques ann=E9es pour d=E9couvrir=20
l'existence de cette m=E9thode !
Oui, je sais, je viens de v=E9rifier et, effectivement, elle est bien=20
d=E9crite page 101 (para. 15.5.4.9) du standard ECMA 262-3.
Mais quand m=EAme, comme je pense ne pas =EAtre le seul =E0 m'=E9tonner (=
et =E0 ne=20
pas avoir comme livre de chevet pr=E9f=E9r=E9 l'ouvrage pr=E9cit=E9), je =
me=20
permets d'en faire profiter tout le monde.
La m=E9thode compare la cha=EEne courante avec celle pass=E9e en argument=
,=20
tenant compte des param=E8tres linguistiques de la machine locale.
Ainsi, en fran=E7ais, le "=E9" sera bien consid=E9r=E9 comme =E9tant plac=
=E9 avant=20
le "f", par exemple.
L'exemple ci-dessous utilise la m=E9thode dans une fonction permettant=20
finalement le tri localis=E9 d'un tableau, =E0 comparer avec les r=E9sult=
ats=20
pr=E9c=E9dents.
Oui, sans doute pas pour un array de qqes éléments, mais pour un classement des mots d'un fichier texte de 500 ko ça doit commencer à compter, j'imagine.
Ok, je ne discuterai pas trop ce point, bien que 500 Ko à traiter côt é client ça devrait pas se trouver tous les jours ;-). L'idée d'inverser le sens de la fonction me convient très bien. En fait, je n'y avait pas pensé !
Heu ... c'est plus pour simplifier l'emploi de la fonction - s'il n'y a pas d'argument : tri ascendant (normal) - si n'importe quel(s) argument(s) : tri descendant (inverse)
Compris, mais comme je rajoute une méthode sur le noyau, il me semblait plus juste d'imiter la syntaxe habituelle du langage. Or je ne trouve rien de la sorte dans les fonctions existantes.
Et puis, de mon point de vue, la lisibilité du code n'est pas idéale avec la syntaxe proposée. Je comprends plus facilement, à la relecture : <script>tab.localeSort("desc")</script> que : <script>tab.localeSort(0)</script> ou même : <script>tab.localeSort(false)</script>
Quitte à changer le fusil d'épaule, autant diviser le code en deux fonctions, comme sur le modèle "toLowerCase" et "toUpperCase". Cela pourrait donner : "localeSort" et "localeRSort", par exemple. A voir...
Ha! l'array suivant qui contient des nombres va donner une erreur dans la fonction :
var t = ['fée','add','ferrer','perte','faire','pépite', 'fête','faite','ferraille','ajout','ferré', '0',100,-358,1.25,1.15];
ne reste donc qu'à trouver une astuce pour déterminer la "légitim ité" de - l'array - ou de chacun de ses éléments
Effectivement, j'ai négligé ce point. Il me semble que l'une des solutions logique serait de considérer tous les éléments du tableau comme de chaînes, sans pour autant les conv ertir.
Le code deviendrait donc, en conservant la syntaxe d'origine : http://www.copypastecode.com/28834/
Cordialement, Pascal
SAM a écrit :
Oui, sans doute pas pour un array de qqes éléments,
mais pour un classement des mots d'un fichier texte de 500 ko
ça doit commencer à compter, j'imagine.
Ok, je ne discuterai pas trop ce point, bien que 500 Ko à traiter côt é
client ça devrait pas se trouver tous les jours ;-).
L'idée d'inverser le sens de la fonction me convient très bien.
En fait, je n'y avait pas pensé !
Heu ... c'est plus pour simplifier l'emploi de la fonction
- s'il n'y a pas d'argument : tri ascendant (normal)
- si n'importe quel(s) argument(s) : tri descendant (inverse)
Compris, mais comme je rajoute une méthode sur le noyau, il me semblait
plus juste d'imiter la syntaxe habituelle du langage.
Or je ne trouve rien de la sorte dans les fonctions existantes.
Et puis, de mon point de vue, la lisibilité du code n'est pas idéale
avec la syntaxe proposée.
Je comprends plus facilement, à la relecture :
<script>tab.localeSort("desc")</script>
que :
<script>tab.localeSort(0)</script>
ou même :
<script>tab.localeSort(false)</script>
Quitte à changer le fusil d'épaule, autant diviser le code en deux
fonctions, comme sur le modèle "toLowerCase" et "toUpperCase".
Cela pourrait donner : "localeSort" et "localeRSort", par exemple.
A voir...
Ha! l'array suivant qui contient des nombres
va donner une erreur dans la fonction :
var t = ['fée','add','ferrer','perte','faire','pépite',
'fête','faite','ferraille','ajout','ferré',
'0',100,-358,1.25,1.15];
ne reste donc qu'à trouver une astuce pour déterminer la "légitim ité" de
- l'array
- ou de chacun de ses éléments
Effectivement, j'ai négligé ce point.
Il me semble que l'une des solutions logique serait de considérer tous
les éléments du tableau comme de chaînes, sans pour autant les conv ertir.
Le code deviendrait donc, en conservant la syntaxe d'origine :
http://www.copypastecode.com/28834/
Oui, sans doute pas pour un array de qqes éléments, mais pour un classement des mots d'un fichier texte de 500 ko ça doit commencer à compter, j'imagine.
Ok, je ne discuterai pas trop ce point, bien que 500 Ko à traiter côt é client ça devrait pas se trouver tous les jours ;-). L'idée d'inverser le sens de la fonction me convient très bien. En fait, je n'y avait pas pensé !
Heu ... c'est plus pour simplifier l'emploi de la fonction - s'il n'y a pas d'argument : tri ascendant (normal) - si n'importe quel(s) argument(s) : tri descendant (inverse)
Compris, mais comme je rajoute une méthode sur le noyau, il me semblait plus juste d'imiter la syntaxe habituelle du langage. Or je ne trouve rien de la sorte dans les fonctions existantes.
Et puis, de mon point de vue, la lisibilité du code n'est pas idéale avec la syntaxe proposée. Je comprends plus facilement, à la relecture : <script>tab.localeSort("desc")</script> que : <script>tab.localeSort(0)</script> ou même : <script>tab.localeSort(false)</script>
Quitte à changer le fusil d'épaule, autant diviser le code en deux fonctions, comme sur le modèle "toLowerCase" et "toUpperCase". Cela pourrait donner : "localeSort" et "localeRSort", par exemple. A voir...
Ha! l'array suivant qui contient des nombres va donner une erreur dans la fonction :
var t = ['fée','add','ferrer','perte','faire','pépite', 'fête','faite','ferraille','ajout','ferré', '0',100,-358,1.25,1.15];
ne reste donc qu'à trouver une astuce pour déterminer la "légitim ité" de - l'array - ou de chacun de ses éléments
Effectivement, j'ai négligé ce point. Il me semble que l'une des solutions logique serait de considérer tous les éléments du tableau comme de chaînes, sans pour autant les conv ertir.
Le code deviendrait donc, en conservant la syntaxe d'origine : http://www.copypastecode.com/28834/
Cordialement, Pascal
SAM
Le 5/16/10 3:56 PM, Pascal a écrit :
Et puis, de mon point de vue, la lisibilité du code n'est pas idéale avec la syntaxe proposée. Je comprends plus facilement, à la relecture : <script>tab.localeSort("desc")</script> que : <script>tab.localeSort(0)</script> ou même : <script>tab.localeSort(false)</script>
c'est bien pourquoi, de mon côté je préfère : (argument.length>0)?
- pas d'argument --> tri normal - un argument --> tri inverse (0, 1, true, false, un nombre, une chaine, ce qu'on veut)
même si syntaxiquement ce n'est pas le top au moins ce n'est pas pénible à appeler (ni pour le ciboulot ni pour la mimine), bien que non exempt, ne sera pas cause de trop d'erreurs d'écriture, l'argument étant très "souple".
et puis ça rejoint l'idée du 'asc' optionnel.
Quitte à changer le fusil d'épaule, autant diviser le code en deux fonctions, comme sur le modèle "toLowerCase" et "toUpperCase". Cela pourrait donner : "localeSort" et "localeRSort", par exemple.
aussi.
-- sm
Le 5/16/10 3:56 PM, Pascal a écrit :
Et puis, de mon point de vue, la lisibilité du code n'est pas idéale
avec la syntaxe proposée.
Je comprends plus facilement, à la relecture :
<script>tab.localeSort("desc")</script>
que :
<script>tab.localeSort(0)</script>
ou même :
<script>tab.localeSort(false)</script>
c'est bien pourquoi, de mon côté je préfère :
(argument.length>0)?
- pas d'argument --> tri normal
- un argument --> tri inverse
(0, 1, true, false, un nombre, une chaine, ce qu'on veut)
même si syntaxiquement ce n'est pas le top
au moins ce n'est pas pénible à appeler
(ni pour le ciboulot ni pour la mimine),
bien que non exempt, ne sera pas cause de trop d'erreurs d'écriture,
l'argument étant très "souple".
et puis ça rejoint l'idée du 'asc' optionnel.
Quitte à changer le fusil d'épaule, autant diviser le code en deux
fonctions, comme sur le modèle "toLowerCase" et "toUpperCase".
Cela pourrait donner : "localeSort" et "localeRSort", par exemple.
Et puis, de mon point de vue, la lisibilité du code n'est pas idéale avec la syntaxe proposée. Je comprends plus facilement, à la relecture : <script>tab.localeSort("desc")</script> que : <script>tab.localeSort(0)</script> ou même : <script>tab.localeSort(false)</script>
c'est bien pourquoi, de mon côté je préfère : (argument.length>0)?
- pas d'argument --> tri normal - un argument --> tri inverse (0, 1, true, false, un nombre, une chaine, ce qu'on veut)
même si syntaxiquement ce n'est pas le top au moins ce n'est pas pénible à appeler (ni pour le ciboulot ni pour la mimine), bien que non exempt, ne sera pas cause de trop d'erreurs d'écriture, l'argument étant très "souple".
et puis ça rejoint l'idée du 'asc' optionnel.
Quitte à changer le fusil d'épaule, autant diviser le code en deux fonctions, comme sur le modèle "toLowerCase" et "toUpperCase". Cela pourrait donner : "localeSort" et "localeRSort", par exemple.
aussi.
-- sm
Pierre Goiffon
On 11/05/2010 16:13, Olivier Miakinen wrote:
Euh mais où sont récupérés les fameux paramètres ?
Pas compris le sens de la question.
À mon avis, Pierre se demande quelle locale est utilisée (réponse : celle du système si j'ai bien tout compris).
C'était exactement ce dont je me demandais : sur quoi la fonction se base pour décider de la locale. Comme olivier et par expérience, les fonctionnalités s'appuyant sur la locale du navigateur ou du système sont très peu souvent "utilisables" en cas réel.
On 11/05/2010 16:13, Olivier Miakinen wrote:
Euh mais où sont récupérés les fameux paramètres ?
Pas compris le sens de la question.
À mon avis, Pierre se demande quelle locale est utilisée (réponse :
celle du système si j'ai bien tout compris).
C'était exactement ce dont je me demandais : sur quoi la fonction se
base pour décider de la locale.
Comme olivier et par expérience, les fonctionnalités s'appuyant sur la
locale du navigateur ou du système sont très peu souvent "utilisables"
en cas réel.
Euh mais où sont récupérés les fameux paramètres ?
Pas compris le sens de la question.
À mon avis, Pierre se demande quelle locale est utilisée (réponse : celle du système si j'ai bien tout compris).
C'était exactement ce dont je me demandais : sur quoi la fonction se base pour décider de la locale. Comme olivier et par expérience, les fonctionnalités s'appuyant sur la locale du navigateur ou du système sont très peu souvent "utilisables" en cas réel.
SAM
Le 5/18/10 3:00 PM, Pierre Goiffon a écrit :
On 11/05/2010 16:13, Olivier Miakinen wrote:
Euh mais où sont récupérés les fameux paramètres ?
À mon avis, Pierre se demande quelle locale est utilisée (réponse : celle du système si j'ai bien tout compris).
C'était exactement ce dont je me demandais : sur quoi la fonction se base pour décider de la locale. Comme olivier et par expérience, les fonctionnalités s'appuyant sur la locale du navigateur ou du système sont très peu souvent "utilisables" en cas réel.
C'est sûr que si on veux trier du russe en se basant sur un ordre système qu'on ne connait pas (probablement français de par ici), ça va pas le faire ;-)
Comme je n'ai aucune idée de l'ordre de tri en russe, est-ce que ça arrivera un peu à trier ? (en se basant sur les index des caractères ?)
Bon ... personnellement si du JS me liste des mots russes triés en ascendant, ça va pas bp me changer du mode aléatoire ;-)
On peut espérer que ce sera un russe (ou un étudiant qui sera passé en système russe) qui se récupèrera l'truc, surtout si toute la page est dans cette langue.
Le chinois ? Ha! Oui! je vous remercie de la question ! ! !
En tous cas sur une liste de mots russes ça trie touj pareil que je demande au système le tri russe ou français tant en sort normal qu'en localCompare (avec Fx.3) mais ... peut-être sont-ce les mêmes ordre de tri ?
-- sm
Le 5/18/10 3:00 PM, Pierre Goiffon a écrit :
On 11/05/2010 16:13, Olivier Miakinen wrote:
Euh mais où sont récupérés les fameux paramètres ?
À mon avis, Pierre se demande quelle locale est utilisée (réponse :
celle du système si j'ai bien tout compris).
C'était exactement ce dont je me demandais : sur quoi la fonction se
base pour décider de la locale.
Comme olivier et par expérience, les fonctionnalités s'appuyant sur la
locale du navigateur ou du système sont très peu souvent "utilisables"
en cas réel.
C'est sûr que si on veux trier du russe en se basant sur un ordre
système qu'on ne connait pas (probablement français de par ici), ça va
pas le faire ;-)
Comme je n'ai aucune idée de l'ordre de tri en russe, est-ce que ça
arrivera un peu à trier ? (en se basant sur les index des caractères ?)
Bon ... personnellement si du JS me liste des mots russes triés en
ascendant, ça va pas bp me changer du mode aléatoire ;-)
On peut espérer que ce sera un russe (ou un étudiant qui sera passé en
système russe) qui se récupèrera l'truc, surtout si toute la page est
dans cette langue.
Le chinois ? Ha! Oui! je vous remercie de la question ! ! !
En tous cas sur une liste de mots russes ça trie touj pareil
que je demande au système le tri russe ou français
tant en sort normal qu'en localCompare
(avec Fx.3)
mais ... peut-être sont-ce les mêmes ordre de tri ?
Euh mais où sont récupérés les fameux paramètres ?
À mon avis, Pierre se demande quelle locale est utilisée (réponse : celle du système si j'ai bien tout compris).
C'était exactement ce dont je me demandais : sur quoi la fonction se base pour décider de la locale. Comme olivier et par expérience, les fonctionnalités s'appuyant sur la locale du navigateur ou du système sont très peu souvent "utilisables" en cas réel.
C'est sûr que si on veux trier du russe en se basant sur un ordre système qu'on ne connait pas (probablement français de par ici), ça va pas le faire ;-)
Comme je n'ai aucune idée de l'ordre de tri en russe, est-ce que ça arrivera un peu à trier ? (en se basant sur les index des caractères ?)
Bon ... personnellement si du JS me liste des mots russes triés en ascendant, ça va pas bp me changer du mode aléatoire ;-)
On peut espérer que ce sera un russe (ou un étudiant qui sera passé en système russe) qui se récupèrera l'truc, surtout si toute la page est dans cette langue.
Le chinois ? Ha! Oui! je vous remercie de la question ! ! !
En tous cas sur une liste de mots russes ça trie touj pareil que je demande au système le tri russe ou français tant en sort normal qu'en localCompare (avec Fx.3) mais ... peut-être sont-ce les mêmes ordre de tri ?
-- sm
Pierre Goiffon
On 18/05/2010 16:30, SAM wrote:
En tous cas sur une liste de mots russes ça trie touj pareil que je demande au système le tri russe ou français tant en sort normal qu'en localCompare (avec Fx.3) mais ... peut-être sont-ce les mêmes ordre de tri ?
Incapable de répondre à cette question. As tu à disposition cette "liste de mots russes" ? Ca serait intéressant de comparer avec une bdd dont on fait varier la collation...
Je viens de voir que MySQL s'appuie sur un algorithme Unicode : en effet http://dev.mysql.com/doc/refman/5.0/fr/charset-mysql.html renvoit vers http://www.unicode.org/reports/tr10/.
On 18/05/2010 16:30, SAM wrote:
En tous cas sur une liste de mots russes ça trie touj pareil
que je demande au système le tri russe ou français
tant en sort normal qu'en localCompare
(avec Fx.3)
mais ... peut-être sont-ce les mêmes ordre de tri ?
Incapable de répondre à cette question. As tu à disposition cette "liste
de mots russes" ? Ca serait intéressant de comparer avec une bdd dont on
fait varier la collation...
Je viens de voir que MySQL s'appuie sur un algorithme Unicode : en effet
http://dev.mysql.com/doc/refman/5.0/fr/charset-mysql.html renvoit vers
http://www.unicode.org/reports/tr10/.
En tous cas sur une liste de mots russes ça trie touj pareil que je demande au système le tri russe ou français tant en sort normal qu'en localCompare (avec Fx.3) mais ... peut-être sont-ce les mêmes ordre de tri ?
Incapable de répondre à cette question. As tu à disposition cette "liste de mots russes" ? Ca serait intéressant de comparer avec une bdd dont on fait varier la collation...
Je viens de voir que MySQL s'appuie sur un algorithme Unicode : en effet http://dev.mysql.com/doc/refman/5.0/fr/charset-mysql.html renvoit vers http://www.unicode.org/reports/tr10/.
Olivier Miakinen
Le 21/05/2010 10:20, Pierre Goiffon a écrit :
Je viens de voir que MySQL s'appuie sur un algorithme Unicode : en effet http://dev.mysql.com/doc/refman/5.0/fr/charset-mysql.html renvoie vers http://www.unicode.org/reports/tr10/.
Un grand merci pour ce pointeur. C'est assez ardu à lire, mais très enrichissant.
Pour info, à condition de supprimer tous les fonds de couleur (pour ma part j'ai imprimé le document sur une imprimante noir et blanc), la proposition de mise à jour est souvent plus facile à comprendre : <http://www.unicode.org/reports/tr10/tr10-21.html>.
Le 21/05/2010 10:20, Pierre Goiffon a écrit :
Je viens de voir que MySQL s'appuie sur un algorithme Unicode : en effet
http://dev.mysql.com/doc/refman/5.0/fr/charset-mysql.html renvoie vers
http://www.unicode.org/reports/tr10/.
Un grand merci pour ce pointeur. C'est assez ardu à lire, mais très
enrichissant.
Pour info, à condition de supprimer tous les fonds de couleur (pour ma
part j'ai imprimé le document sur une imprimante noir et blanc), la
proposition de mise à jour est souvent plus facile à comprendre :
<http://www.unicode.org/reports/tr10/tr10-21.html>.
Je viens de voir que MySQL s'appuie sur un algorithme Unicode : en effet http://dev.mysql.com/doc/refman/5.0/fr/charset-mysql.html renvoie vers http://www.unicode.org/reports/tr10/.
Un grand merci pour ce pointeur. C'est assez ardu à lire, mais très enrichissant.
Pour info, à condition de supprimer tous les fonds de couleur (pour ma part j'ai imprimé le document sur une imprimante noir et blanc), la proposition de mise à jour est souvent plus facile à comprendre : <http://www.unicode.org/reports/tr10/tr10-21.html>.
