Probablement parce que les objets permettent de contourner gracieusement tous les problemes que t'as mentionne juste au dessus.
Les tableaux sont des objects, certes, mais je peux faire string[5]='t' sur une chaine que je suis pas cense modifier et me retrouver avec un beau depassement de pointeur en cadeau bonux.
Bon courage pour faire pareil avec un object.
Si les tableaux sont des objets, on peut "faire pareil" avec des objets, par définition. Tu n'as pas l'impression de te contredire ?
Le problème n'est pas de savoir comment sont stockées les données en mémoire, mais quelle interface tu fournis pour les manipuler. Si tu donnes à ton objet la même interface qu'un tableau, tu as les mêmes problèmes qu'avec un tableau, la concision de la syntaxe en moins.
Par exemple, les "problèmes UTF" que j'ai cité viennent du fait que, pour des chaînes UTF, la sémantique de l'indexation des caractères n'a pas vraiment de sens : quand tu dis str[1], ça peut vouloir dire le deuxième octet, ou le deuxième code point, et ça peut dépendre de quelle genre de normalisation est utilisée. Le problème fondamental c'est d'imaginer que tu as une opération d'accès à un index donné. Si ton objet te permets d'écrire des 'subrange' délimitées par des indices numériques, ça va poser des problèmes avec Unicode, tout autant que les 'slices' de Go.
De même, c'est évident mais si ton objet ne fait de vérification quand tu accès à un indice de la chaîne, il peut provoquer des segfault aussi.
Le fait de dire "c'est un objet" ne change rien et n'apporte rien, la question est de savoir quelle est l'interface proposée, et quel est le comportement garanti (vérifications d'accès ou pas, etc.).
[^] # Re: c'est moi ou bien...
Posté par gasche . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 5.
Si les tableaux sont des objets, on peut "faire pareil" avec des objets, par définition. Tu n'as pas l'impression de te contredire ?
Le problème n'est pas de savoir comment sont stockées les données en mémoire, mais quelle interface tu fournis pour les manipuler. Si tu donnes à ton objet la même interface qu'un tableau, tu as les mêmes problèmes qu'avec un tableau, la concision de la syntaxe en moins.
Par exemple, les "problèmes UTF" que j'ai cité viennent du fait que, pour des chaînes UTF, la sémantique de l'indexation des caractères n'a pas vraiment de sens : quand tu dis str[1], ça peut vouloir dire le deuxième octet, ou le deuxième code point, et ça peut dépendre de quelle genre de normalisation est utilisée. Le problème fondamental c'est d'imaginer que tu as une opération d'accès à un index donné. Si ton objet te permets d'écrire des 'subrange' délimitées par des indices numériques, ça va poser des problèmes avec Unicode, tout autant que les 'slices' de Go.
De même, c'est évident mais si ton objet ne fait de vérification quand tu accès à un indice de la chaîne, il peut provoquer des segfault aussi.
Le fait de dire "c'est un objet" ne change rien et n'apporte rien, la question est de savoir quelle est l'interface proposée, et quel est le comportement garanti (vérifications d'accès ou pas, etc.).