Posté par PR .
En réponse au journal C, un âge remarquable.
Évalué à 7.
Dernière modification le 03 mars 2022 à 11:18.
C’est surtout que ça compare pas deux caractères (le point de code au sens Unicode est ce qui se rapproche le plus de la notion usuelle de caractère), mais deux rendus supposément identiques.
Le problème c’est que ça n’a rien :
1/ de prédictible
2/ d’universel
Savoir si deux caractères (ie. point de code) sont et/ou doivent être identiques en rendu (ie. glyphe), c’est un problème très complexe (ça va dépendre du moteur de rendu de l’utilisateur en particulier, mais aussi de considérations sémantiques et donc de la langue...). Et avoir foutu ça comme comportement par défaut d’un langage de programmation, c’est juste une immense connerie. Ça fait faussement croire à une facilité, une feature, pour le développeur, mais ça porte en soit des effets de bords difficilement maîtrisables.
Un langage bien conçu, aurait dû garder == (ie. la comparaison de base) comme une égalité d’encodage (même pas un égalité de point de code!), c’est-à-dire une comparaison bit-à-bit au final ET proposer en lib standard des outils de comparaison plus évolués :
1. Comparaison de point de code : ce qui oblige à connaître l’encodage du texte comparé, ce que le == n’indique pas du tout — nécessairement il admet implicitement un encodage, mais lequel ?
2. Comparaison de glyphes (ce qui oblige en plus à avoir des tables de caractères "qui se ressemblent", avec tout le flou que ça induit)
PS : un point de vocabulaire rapide. Unicode, c’est une norme d’identification des caractères : elle attribue (entre autres, mais pas que) un point de code à chaque caractère. Un encodage unicode (utf-X par exemple) ça va être une norme qui établie une correspondance entre un point de code et une valeur en mémoire informatique (l’encodage ne couvre pas nécessairement tout unicode, par exemple UCS-2, et du coup je dirais que l’ascii est un encodage unicode, si je voulais troller). Le glyphe est la représentation graphique du dit caractère, lui-même très différent de la représentation finale qui va être constitué d’une lettre et d’un ou plusieurs signes diacritiques (par exemple). Il n’y a pas de correspondance 1 à 1 entre glyphe, point de code et encodage (même en ascii car & c’est un et ligaturé à la base, qui est devenu caractère autonome par évolution de l’usage...). De plus un caractère ne se définit pas seulement par sa représentation graphique, mais aussi par son comportement dans une phrase (ligature, césure, etc.). Et depuis le début on ne parle que d’alphabets latins... là on parle du cas archi-ultra-méga simple (même unicode est criticable selon certains linguistes).
PPS : si vous voulez coder propre, portable, soyez générique, ne rendez pas votre code dépendant d’un système d’encodage / de codification de caractères particulier, faites le moins d’hypothèse possible sur les données que vous traitez (y compris hypothèses implicites / cachées). Donc autant que faire se peut considérez du texte comme un simple paquet de bytes en étant totalement agnostique vis-à-vis de sa représentation interne. Je travaille dans un domaine où il n’est pas extraordinaire de trouver que même l’ascii est trop large et où on stocke que des majuscules (pas d’ambivalence entre majuscule et minuscule : ah ouai tiens d’ailleurs tu compares comment majuscule et minuscule ? Si c’est en début de phrase c’est le même caractère ? Si c’est pour un nom propre c’est plus le même ? Et si c’est un nom propre en début de phrase ? Ton == il doit faire une analyse sémantique pour savoir, où il met juste sous le tapis le problème ?)
[^] # Re: Survivor
Posté par PR . En réponse au journal C, un âge remarquable. Évalué à 7. Dernière modification le 03 mars 2022 à 11:18.
C’est surtout que ça compare pas deux caractères (le point de code au sens Unicode est ce qui se rapproche le plus de la notion usuelle de caractère), mais deux rendus supposément identiques.
Le problème c’est que ça n’a rien :
1/ de prédictible
2/ d’universel
Savoir si deux caractères (ie. point de code) sont et/ou doivent être identiques en rendu (ie. glyphe), c’est un problème très complexe (ça va dépendre du moteur de rendu de l’utilisateur en particulier, mais aussi de considérations sémantiques et donc de la langue...). Et avoir foutu ça comme comportement par défaut d’un langage de programmation, c’est juste une immense connerie. Ça fait faussement croire à une facilité, une feature, pour le développeur, mais ça porte en soit des effets de bords difficilement maîtrisables.
Un langage bien conçu, aurait dû garder == (ie. la comparaison de base) comme une égalité d’encodage (même pas un égalité de point de code!), c’est-à-dire une comparaison bit-à-bit au final ET proposer en lib standard des outils de comparaison plus évolués :
1. Comparaison de point de code : ce qui oblige à connaître l’encodage du texte comparé, ce que le == n’indique pas du tout — nécessairement il admet implicitement un encodage, mais lequel ?
2. Comparaison de glyphes (ce qui oblige en plus à avoir des tables de caractères "qui se ressemblent", avec tout le flou que ça induit)
PS : un point de vocabulaire rapide. Unicode, c’est une norme d’identification des caractères : elle attribue (entre autres, mais pas que) un point de code à chaque caractère. Un encodage unicode (utf-X par exemple) ça va être une norme qui établie une correspondance entre un point de code et une valeur en mémoire informatique (l’encodage ne couvre pas nécessairement tout unicode, par exemple UCS-2, et du coup je dirais que l’ascii est un encodage unicode, si je voulais troller). Le glyphe est la représentation graphique du dit caractère, lui-même très différent de la représentation finale qui va être constitué d’une lettre et d’un ou plusieurs signes diacritiques (par exemple). Il n’y a pas de correspondance 1 à 1 entre glyphe, point de code et encodage (même en ascii car
&c’est un et ligaturé à la base, qui est devenu caractère autonome par évolution de l’usage...). De plus un caractère ne se définit pas seulement par sa représentation graphique, mais aussi par son comportement dans une phrase (ligature, césure, etc.). Et depuis le début on ne parle que d’alphabets latins... là on parle du cas archi-ultra-méga simple (même unicode est criticable selon certains linguistes).PPS : si vous voulez coder propre, portable, soyez générique, ne rendez pas votre code dépendant d’un système d’encodage / de codification de caractères particulier, faites le moins d’hypothèse possible sur les données que vous traitez (y compris hypothèses implicites / cachées). Donc autant que faire se peut considérez du texte comme un simple paquet de bytes en étant totalement agnostique vis-à-vis de sa représentation interne. Je travaille dans un domaine où il n’est pas extraordinaire de trouver que même l’ascii est trop large et où on stocke que des majuscules (pas d’ambivalence entre majuscule et minuscule : ah ouai tiens d’ailleurs tu compares comment majuscule et minuscule ? Si c’est en début de phrase c’est le même caractère ? Si c’est pour un nom propre c’est plus le même ? Et si c’est un nom propre en début de phrase ? Ton == il doit faire une analyse sémantique pour savoir, où il met juste sous le tapis le problème ?)
Mort aux cons !