(une petite traduction rapide des changements impactant entre la v5 et la v3. les numéros correspondent aux chapitres de la norme)

Ecma-362 alias EcmaScript5
Annexe E
Ajouts et modifications dans la 5e édition qui introduisent des incompatibilités avec la 3e édition


7.1: si des caractères de contrôle Unicode sont présent dans une expression String ou une expression d'ExpressionRegulière ils seront inclus dans la l'expression. alors que dans l’édition 3 ils étaient ignorés.

7.2: le caractère Unicode <BOM> (Byte Order Mark) est maintenant traité comme un whitespace alors qu'il provoquait une Syntax Error dans l'édition 3.

7.3: les caractères de fin de ligne précédés d'une séquence d'échappement sont désormais autorisés dans un token de chaîne littérale. Dans l'édition 3, une erreur de syntaxe aurait été produite.

7.8.5: Les expressions rationnelles retournent maintenant un objet unique chaque fois que le littéral est évalué. Ce changement est détectable par les programmes qui testent l'identité objet de ces valeurs littérales ou qui sont sensibles aux effets secondaires communs.

7.8.5: Edition 5 exige le signalement anticipé des éventuelles erreurs constructeur RegExp qui seraient produites lors de la conversion d'une expression rationnelle en objet RegExp. Avant Edition 5 les implémentations étaient autorisés à reporter le rapport de ces erreurs au moment de l'exécution réelle de l'objet.

7.8.5: Dans Edition 5 les caractères - / ‖ non échappés peuvent apparaître comme une classe de caractère dans une expression régulière littérale. Dans Edition 3 de tels caractères aurait été interprété comme caractères définitifs du littéral.

10.4.2: Dans l'édition 5, les appels indirects à la fonction eval utilisent l'environnement global à la fois pour les variables et pour l'environnement lexical. Dans l'édition 3, l’environnement de l'appelant était utilisé.

15.4.4: Dans Edition 5 toutes les méthodes de Array.prototype sont intentionnellement générique. Dans Edition 3 toString et toLocaleString n'étaient pas générique et levaient une exception TypeError si elle est appliquée à des objets qui n'étaient pas des instances de Array.

10.6: Dans l'édition 5, le tableau indexé des arguments correspondant aux paramètres formels sont énumérables. Dans l'édition 3, ces tableaux ne sont pas énumérable.

10.6: Dans l'édition 5 la propriété interne d'un objet arguments est «arguments». Dans l'édition 3, il était «Object». Ceci est observable si toString est appelée en tant que méthode d'un objet arguments.

12.6.4: for-in statements ne lève plus une TypeError si le l'expression prend la valeur null ou undefined. Au lieu de cela, la déclaration se comporte comme si la valeur de l'expression était un objet sans propriétés énumérables.

15: Dans l'édition 5, les nouvelles propriétés suivantes sont définies sur les built-in objects qui existaient dans Edition 3:
Object.getPrototypeOf, Object.getOwnPropertyDescriptor, Object.getOwnPropertyNames,
Object.create, Object.defineProperty, Object.defineProperties, Object.seal,
Object.freeze, Object.preventExtensions, Object.isSealed, Object.isFrozen,
Object.isExtensible, Object.keys, Function.prototype.bind, Array.prototype.indexOf,
Array.prototype.lastIndexOf, Array.prototype.every, Array.prototype.some,
Array.prototype.forEach, Array.prototype.map, Array.prototype.filter,
Array.prototype.reduce, Array.prototype.reduceRight, String.prototype.trim, Date.now,
Date.prototype.toISOString, Date.prototype.toJSON
Les implémentations sont désormais tenus de ne pas tenir compte des arguments supplémentaires au méthodes standards sauf dispositions contraires expressément spécifiées. Dans l'édition 3 la manipulation des arguments supplémentaires n'a pas été précisée et les implémentations étaient explicitement autorisés à lever une exception TypeError.

15.1.1: La valeur des propriétés NaN, Infinity, et indéfini des objets globaux ont été modifiés pour être en lecture seule.

15.1.2.1. Les implémentations ne sont plus autorisés à restreindre l'utilisation de eval lorsque ce n'est pas un appel direct. En outre, toute invocation de eval qui n'est pas un appel direct utilise l'environnement global et non l'environnement de l'appelant.

15.1.2.2: La spécification de la fonction parseInt ne permet plus aux implémentations de traiter des chaînes commençant par un caractère 0 comme valeurs octales.

15.3.4.3: Dans l'édition 3, une TypeError est levée si le deuxième argument passé à
la fonction Function.prototype.apply n'est ni un objet tableau ni un objet arguments. Dans l'édition 5, le second argument peut être n'importe quel type de générique de type tableau qui possède une propriété length valide.

15.3.4.3, 15.3.4.4: In Edition 3 passer undefined ou null comme premier argument à
Function.prototype.apply ou Function.prototype.call revient à passer indirectement l'objet global comme argument à la fonction.
Si le premier argument est une valeur primitive le résultat de l'appel à ToObject sur ​​cette valeur est passé comme la argument.
Dans l'édition 5, ces transformations ne sont pas réalisées et la valeur premier argument est passé comme argument.
Cette différence sera normalement pas observables sur un code ECMAScript Edition 3 existant car une transformation correspondante a lieu lors de l'activation de la fonction cible.
Toutefois, en fonction de l'implémentation, cette différence peut être observée par des appel à Apply ou Call. En outre, invoquer une interne avec undefined ou null peut dans de nombreux cas provoquer un comportement dans l'édition 5 diffèrent de l'édition 3. En particulier, dans Edition 5 les fonction interne qui spécifient le passage d'un objet, lèvent une exception TypeError si on leur passe undefined ou null en paramètre.

15.3.5.2: Dans l' Edition 5, la propriété prototype d'une instance de Function n'est pas énumérable. Dans l'Edition 3, cette propriété était énumérable.

15.5.5.2: Dans l'édition 5, les caractères individuels d'un objet chaîne [[PrimitiveValue] peut être consultée en tant que tableau indexé de propriétés de l'objet String. Ces propriétés sont en lecture seule et non configurable de plus elles masquent toutes les propriétés héritées avec les mêmes noms. Dans l'édition 3, ces propriétés n'existent pas et le code ECMAScript pouvait ajouter et supprimer des propriétés accessibles en écriture avec ces noms et pouvait accéder à des propriétés héritées de même noms.

15.9.4.2: Date.parse est maintenant nécessaire lors de la première tentative pour analyser son argument comme une chaîne au format ISO. Les programmes qui utilisent ce format, mais dépendait de la mise en œuvre des comportements spécifiques (y compris l'insuffisance) peuvent se comporter différemment.

15.10.2.12: Dans l'édition 5, \s correspond maintenant à <BOM>.

15.10.4.1: Dans l'édition 3, la forme exacte de la chaîne d'une propriété d'un objet créé par le constructeur RegExp est défini par l'implémentation. Dans l'édition 5, la chaîne doit se conformer à certaines exigences spécifiées et peuvent donc être différente de celle produite par une édition 3.

15.10.6.4: Dans l'édition 3, le résultat de RegExp.prototype.toString n'est pas tenu de dériver de la propriété source de l'objet RegExp. Dans l'édition 5, le résultat doit être dérivée de la propriété source de la façon spécifique et peut donc être différent du résultat produit par une édition 3

15.11.2.1, 15.11.4.3: Dans l'édition 5, si une valeur initiale du message d'un objet d'erreur n'est pas précisée par le constructeur Error la valeur initiale est la chaîne vide. Dans l'édition 3, la valeur initiale est définie par l'implémentation.

15.11.4.4: Dans l'édition 3, le résultat de Error.prototype.toString est défini par l'implémentation. Dans l'édition 5, le résultat est complètement définie et peut donc différer des implémentations de l'édition 3.

15.12: Dans l'édition 5, le JSON nom est défini dans l'environnement global. Dans l'édition 3, tester la présence de ce nom revoie indéfini jusqu'à qu'il soit défini par programme ou par l’implémentation.

A+JYT