Discussion :

[Hinault Romaric]

ECMA International ratifie la norme JavaScript ECMA-262 Edition 5.1
Interopérabilité entre applications Web au menu

L'International Organization for Standardization (ISO), l'International Electrotechnical Commission (IEC) et ECMA International ont procédé à une ratification de la norme ECMA-262 Edition 5.1.

ECMA-262 définit le langage de script dynamique ECMAScript (JavaScript).

ECMA-262 Edition 5.1 est une mise à jour minime mais nécessaire de la norme. Elle apporte un certain nombre de corrections « d'ordre rédactionnel » et de corrections de bugs.

ECMA-262 Edition 5.1 permet ainsi une meilleure interopérabilité entre les applications Web et rend plus facile la mise en œuvre de la norme précédente (ECMA-262 Edition 5). Elle sera publiée en tant que norme ISO/IEC 16262 Edition 3.

«ECMA-262 Edition 5.1 crée une base solide pour l'évolution future du langage JavaScript standardisé en offrant des fonctionnalités cruciales telles que le mode strict et la Meta-Programming APIs» explique Brendan Eich, directeur technique de Mozilla et principal contributeur de la norme.

Pour la première fois, l'ECMA International a promis qu'il allait publier une suite de tests standardisés permettant aux développeurs de voir jusqu'où l'implémentation d'ECMAScript adhère à la norme actuelle.

Les responsables de la standardisation d'ECMAScript ont également promis une plus grande cohérence du langage avec les différents navigateurs.

Source : ECMA international

Et vous ?

Que pensez-vous des améliorations de la norme ?

[kdmbella]

c'est toujours une bonne chose qu'il y ait une normalisation et une standardisation ça évite d'avoir des fonctions JS qui marche ici et pas là du coup les éditeurs de navigateur n'auront plus qu'à ce conformer à la norme pour nous faciliter la tâche à nous les développeurs

[beekeep]

ECMA-262 définit le langage de script dynamique ECMAScript (JavaScript).

et ActionScript (Flash)

[camus3]

Ca veut dire quoi mode strict ? quel langage digne de ce nom aurait besoin d'un mode strict si il avait été correctement conçu au départ ?

Bref , n'en déplaisent à certain , javascript c'est bien de la m...
ça n’empêche pas qu'on l'utilise pour exploiter des apis , mais c'est juste qu'il est très mal conçu.

typeof MyArray => Object
typeof MyObject => Object
typeof MyString => String

[RomainVALERI]

et ActionScript (Flash)

...et jScript (plus toute autre implémentation particulière, comme celle d'Adobe pour les PDF, Photoshop, etc.) ^^

@camus : oh dis donc t'as vu l'activité qu'il y a à la taverne ! Ils seraient super contents que tu ailles les rejoindre à mon avis ! (j'ai même pas dit le mot "troll" ! ah tiens si... zut )

[Watilin]

Je suis un peu d'accord avec camus… J'ai découvert le mode strict il y a 3 jours ^^ (dans une discussion à propos de with) et j'ai pensé assez vite « tiens, si on oubliait le mode non strict ? ». Le mode strict apporte un gain de performances indéniables (en théorie, car aujourd'hui, il est très peu implémenté).

[NoSmoking]

Bref , n'en déplaisent à certain , javascript c'est bien de la m...

typeof MyArray => Object
typeof MyObject => Object
typeof MyString => String

un peu sévère quand même, mais comme tout est "objet" en javascript l'opérateur typeof est effectivement un peu vérolé et pour retrouver la "class" de l'objet il faut utiliser la méthode toString...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
var getObjectClass = function( obj){
    return Object.prototype.toString.call( obj);
  };
alert( getObjectClass( []));

...de la sorte on obtient ce que l'on souhaite.

ECMAScript Language Specification
- Object.prototype.toString()
- The typeof Operator

[Watilin]

typeof marche bien avec les booléens, nombres, chaînes et fonctions. Mais pas avec Array ni RegExp, même lorsqu'on les déclare de manière littérale :

Code console :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
>>> typeof []
"object"
>>> typeof /^$/
"object"

Pour moi c'est un peu le type natif qui est une aberration en JS : tout n'est pas censé être objet ?

En revanche, on dispose de l'opérateur instanceof, bien pratique si on sait à l'avance quel type on est susceptible de rencontrer :

Code console :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>> [] instanceof Array
true

Là où c'est délicat, c'est si on s'amuse à déclarer des types natifs avec l'opérateur new :

Code console :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
>>> var x = new Number(2)
>>> x instanceof Number
true
>>> typeof x
"object"        // pfff…

Encore mieux :

Code console :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>> 12 instanceof Number
false

jQuery utilise beaucoup de méthodes à paramètres optionnels ou quel l'on peut passer dans n'importe quel ordre ; il n'est pas rare d'y trouver des séquences de détection de type comme celle-ci :

Code JS :

Sélectionner tout - Visualiser dans une fenêtre à part

if (typeof arg1 == "string" || arg1 instanceof String)

Tout ça pour dire quoi ?
JavaScript n'est pas un langage orienté objet. C'est un langage orienté aspect. Un objet n'a pas besoin d'être de tel ou tel type du moment qu'il offre bien les propriétés et méthodes qu'on veut utiliser. C'est le principe du duck typing.

Alors oui, je suis tout à fait d'accord, la détection de type est un gros bordel en JS. Mais à part pour l'exemple de jQuery ci-dessus, je n'ai jamais vu de cas où c'était vraiment nécessaire.

Code JS :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if (method in obj) {
   return obj[method]();
}

Ça, c'est vraiment puissant, non ?

[xelab]

JavaScript n'est pas un langage orienté objet. C'est un langage orienté aspect. Un objet n'a pas besoin d'être de tel ou tel type du moment qu'il offre bien les propriétés et méthodes qu'on veut utiliser. C'est le principe du duck typing.

Si si, c'est bien un langage orienté objet, mais à prototype. Et c'est cette notion de prototype que ne comprennent (voire ne connaissent) pas la plupart des développeurs. Il y a encore quelques semaines, j'en parlais avec un développeur web de formation et de profession qui me disait que pas grand monde ne connaissait vraiment bien javascript. Quand je lui ai parlé du prototypage, il m'a dit: "ah ça je connais pas" . En fait il savait juste utiliser jquery... Ce qui confirmait donc malgré lui sa réflexion sur le manque de connaissance du langage...

[sekaijin]

Ca veut dire quoi mode strict ? quel langage digne de ce nom aurait besoin d'un mode strict si il avait été correctement conçu au départ ?

Bref , n'en déplaisent à certain , javascript c'est bien de la m...
ça n’empêche pas qu'on l'utilise pour exploiter des apis , mais c'est juste qu'il est très mal conçu.

typeof MyArray => Object
typeof MyObject => Object
typeof MyString => String

Ben en java int float boolean char et tout le reste est object. en C int float et char array tout le reste ben c'est rien
en C++ int float char array et le este c'est object

...

maintenant certain langage ont un opérateur typof plus sioux puisqu'il retourne la classe quand c'est un objet.

je ne vois pas de différence entre javascript et les autres langage sur ce point.

si il en existe qui sont beaucoup plus clair. tcl tout est string ou function, en lisp tout est pair (couple), et quelques langages à objets où tout est objet il n'existe pas de type de base comme en java ou js

A+JYT

[sekaijin]

re
ecmaScript normalise le langage

JavaScript n'est qu'une implémentation parmi d'autres
Donc ecmaScript ne normalise pas les chose comme les propriété des objets document ou windows ou HTMLElement etc.

ce que normalise Ecmas est le coeur du langage
c'est qui une fonction comment on dois interpréter le code source etc.

quand à ceux qui s'étonnent du mode Strict
Javascript est né chez NetScape côté serveur
il à rapidement été repris coté client par Netscape mais aussi microsoft puis par d'autres.
à ce moment là il n'existait aucunes instance qui dicte comment doivent êtres faites les choses.

puis Ecma c'est emparé de la chose et à sortie la première norme.
deux solution s'offrait alors. pondre un truc clean et strict et donc exclure TOUTES les implémentations sans exception. le risque étant alors que personne n'adhérant à la norme (cela demanderait trop d'investissement) elle serait morte née.
l'autre solution celle choisie consiste au contraire à faire une norme souple pour embrasser le plus grand nombre. les différents constructeurs n'ont alors que peut de chose à faire pour s'y conformer.

ainsi la norme fut largement adopté. pouvais commencer un processus de convergence. au fil des normes les choses se sont donc mieux structurées.
le mode strict est apparu pour proposer deux niveau à la norme un qui se veux la réalisation de la première option et un autre pour la seconde.
cela permet de conserver les constructeur dans la norme tout en montrant une voie plus "carrée"

ça n'a rien d'étonnant en soit c'est un processus de normalisation comme beaucoup d'autre.
le relatif échec de XHTML face à HTML5 en est un exemple. XHTML se voulait plus strict plut logique plus efficace mais il était trop éloigné des moteurs existant. très peut de fabriquant ont adhéré. les tenant d'une approche plus pragmatique moins contraignante moins structuré on fini par aboutir à HTML5 qui ne rompt pas avec le passé.

on à vécu ça dans java avec les atermoiement des évols de java7 etc.

A+JYT

[gokudomatic]

Ca veut dire quoi mode strict ? quel langage digne de ce nom aurait besoin d'un mode strict si il avait été correctement conçu au départ ?

Bref , n'en déplaisent à certain , javascript c'est bien de la m...
ça n’empêche pas qu'on l'utilise pour exploiter des apis , mais c'est juste qu'il est très mal conçu.

typeof MyArray => Object
typeof MyObject => Object
typeof MyString => String

Effectivement, ça me déplaît. Le concept fondamental du langage ecmascript a fait ses preuves. C'est juste qu'en production, on reste à une version mal achevée qui commence sérieusement à dater.

[Watilin]

C'est juste qu'en production, on reste à une version mal achevée qui commence sérieusement à dater.

Tout à fait d'accord. Et c'est la faute aux implémentateurs. Les éditeurs de navigateurs préfèrent assurer une rétro-compatibilité pour de vieux sites qui ne sont pas maintenus, quitte à saper les performances et présenter des failles de sécurité. Combien d'infections pourraient être évitées si on jetait document.write aux oubliettes ?

J'aimerais bien voir un projet de navigateur « pur ECMA », avez-vous entendu parler d'un truc du genre ?

[SpaceFrog]

galio ?

[sekaijin]

...
Combien d'infections pourraient être évitées si on jetait document.write aux oubliettes ?

Bonjour
ben non ça ce n'est pas normalisé par l'ECMA.
Comme je le disais plus haut l'ECMA normalise le langage pas les objet ajouté par les contexte d'utilisation.

pour ce qui est des objet du navigateur html dom c'est le W3C qui établi la norme

le W3C procède sur se sujet en 2 étapes.
les définitions qui définissent les objets et les méthodes qui y sont associées indépendamment des langages.
puis les Bindings dont l'ECMAScript Binding et le java binding qui sont la façon don le lagage ECMAScript et Java doivent implémenter ces définitions. le W3C ne définit pas d'autre bidings mais pour C++ ou C par exemple il existe des norme sur la façon d'implémenter des IDL (définitions) le W3C se repose donc dessus. normalement un développeur qui veux implémenter le DOM en C/C++ utilise la définition IDL la passe à la moulinette et obtient la définitions C/C++ des objets et leur méthode reste à charge d'implémenter le code. pour php rien de plus simple on prends le source C généré et on le lie au langage php
il en va ainsi de la plus part des langages.

A+JYT

[OPi]

Si si, c'est bien un langage orienté objet, mais à prototype. Et c'est cette notion de prototype que ne comprennent (voire ne connaissent) pas la plupart des développeurs. Il y a encore quelques semaines, j'en parlais avec un développeur web de formation et de profession qui me disait que pas grand monde ne connaissait vraiment bien javascript. Quand je lui ai parlé du prototypage, il m'a dit: "ah ça je connais pas" . En fait il savait juste utiliser jquery... Ce qui confirmait donc malgré lui sa réflexion sur le manque de connaissance du langage...

Effectivement : Programmation orientée prototype

Indeed: JavaScript: The World's Most Misunderstood Programming Language par Douglas Crockford (l'auteur de JSLint et JSON)