Assemblyscript: Le comportement .toUTF8 vs .fromUTF8 est incohérent, déroutant et inefficace

Créé le 23 déc. 2018 · 3Commentaires · Source: AssemblyScript/assemblyscript

WASM est une machine virtuelle de bas niveau, elle devrait donc être capable de gérer des chaînes représentées sous forme de tableaux binaires.
Il existe des méthodes pratiques .fromUTF8 et .toUTF8 : https://github.com/AssemblyScript/assemblyscript/blob/master/std/assembly/string.ts#L499

Cependant, ils sont non symétriques de trois manières :

fromUTF8 nécessite la connaissance de la longueur de la chaîne, tandis que toUTF8 ne renvoie pas cette valeur. Vous devez appeler lengthUTF8 séparément, ce qui est un gaspillage (il est déjà appelé toUTF8 )
fromUTF8 gère correctement les \0 caractères unicode dans les chaînes, tandis que toUTF8 donne l'impression qu'ils ne sont pas pris en charge
fromUTF8 requiert la taille pure de la chaîne encodée en octets, tandis que lengthUTF8 renvoie la taille avec un remplissage de zéro octet. Même les tests existants doivent s'adapter explicitement à cela : https://github.com/AssemblyScript/assemblyscript/blob/b7e7be20cfe2d35c689d7927ee0e4207a443bb6f/tests/compiler/std/string-utf8.ts#L24

C'est une approche inefficace et déroutante. Si l'objectif d'AssemblyScript est d'être un langage de haut niveau compatible avec WASM, alors avoir des C-isms dans la bibliothèque standard comme des pointeurs nus vers des chaînes terminées par null donne l'impression d'aller à l'encontre de ces objectifs.

Ma suggestion serait de renommer .lengthUTF8 et .toUTF8 en .lengthUTF8ZeroTerminated, .toUTF8ZeroTerminated et d'introduire .toUTF8Buffer qui renvoie un ArrayBuffer rempli avec le contenu et la taille corrects. Cette API sera beaucoup plus claire et pratique pour les utilisateurs.

enhancement

Source

kyegupov

👍2

Commentaire le plus utile

Une solution alternative serait d'introduire un type de base comme

class MemSlice {
    constructor(readonly offset: usize, readonly length: usize) {}
    ...
}

ce qui sera bien utile en général

kyegupov le 23 déc. 2018

👍2

Tous les 3 commentaires

Une solution alternative serait d'introduire un type de base comme

class MemSlice {
    constructor(readonly offset: usize, readonly length: usize) {}
    ...
}

ce qui sera bien utile en général

kyegupov le 23 déc. 2018

👍2

D'accord, ces API ne sont pas idéales. Il pourrait même être judicieux de les déplacer hors de la classe de chaînes vers quelque chose ciblant spécifiquement l'interopérabilité (avec C).