Type number une liste key/value

ce post fait suite à celui ci dont je reprend le code javascript qui me pose des nouvelles questions ici .
J'essaie de faire attention au mots employés mais trop de choses implicites ou trop de contextes pour être précis compréhensible ....
NB ; les variables dans la console sont attaché a l onglet actif . Il faut fermer l onglet et réouvrir un nouveau onglet pour n'avoir aucune variables en mémoire .
NB le fait de copier plusieurs lignes de code javascript ( dans ce post) en une seule fois vers la console fait que la console vérifie la syntaxe et l'éxecute le code . si l'étape de la syntaxe et l'execution renvoie une erreur aucun code ne sera exécuté . Y a t il un moyen que la console exécute au moins les lignes qui sont exactes lors de la phase de vérification syntaxe et d'exécution ? ( cela me fait penser au comportement du code SQL )

function f (o) { o.c = 3; }
var num=new Number(3.14);
num // Number {[[PrimitiveValue]]: 3.14}
console.log(num.c); // undefined 
f(num); // undefined
console.log(num.c); //3
num.deux=2 //
num //  Number {c: 3, [[PrimitiveValue]]: 3.14}
num.c // 3 
num.texte="texte" // 
 // ne pas copier cette ligne lors du copier coller global des lignes dans la console 
num.deux * num.texte  //  NaN 
[

rien que cette exemple montre quelque chose d'étonnant : le type Number se comporte comme une liste de clé/valeur !!
Je me demande maintenant
1) comment accéder à la valeur 3.14 selon le contenu de num ?

num.[[PrimitiveValue]]   // Uncaught SyntaxError: Unexpected token
parseFloat(num.toString()) //est la solution  
num.valueOf() // est une autre solution  

donc puis je affirmer qu'une variable object de type number ne peu contenir qu une clé de type PrimitiveValue et que l'on accède à sa valeur par un moyen différent des autres clés/valeurs !!


primitive value me fait penser en CSS à un anonymous region ou en javascript à une fonction anonyme
Enfin un article à lire intéressant sur le concept de [[PrimitiveValue]]

2)Comment avoir acces à la valeur 3.14 dans le dernier object num ( plusieurs key/value)?

num[[[PrimitiveValue]]] //syntaxe bracket  ne fonctionne pas 
num."[[PrimitiveValue]]"   // syntax point ne fonctionne pas 
var vals = Object.keys(num).map(function (key) {
    return num[key];
});
 //si num retourne  Number {c: 3, deux: 2, texte: "texte", texte1: "texte1", [[PrimitiveValue]]: 3.14}
// alors vals contient  [3, 2, "texte", "texte1"] ou est passé 3.14 ??!!!
num1=  {c: 3, deux: 2, texte: "texte"} // Object {c: 3, deux: 2, texte: "texte"}  
 

[[PrimitiveValue]] n'a pas le comportement des clés : c , deux ,"texte" !!!

3) pourquoi javascript accepte

num.texte="texte" 
num //Number {texte: "texte", [[PrimitiveValue]]: 3.14}

Ou est l interêt d utiliser un type Number si le comportement est celui d 'un Object ?
1_ ) je pense que toutes saisie d'entrée ( ici clavier) est convertie en caractère ( uncode/ glyph) sur un GUI pour les humains et en nombre en interne pour la machine mais cela ne semble pas la raison ( voir 2_)
2_) La vérification du au type Number se fait a l appel ( par un code explicite coder par le dev) en sortie pas en entrée !!!
Du fait que javascript est faiblement ( pas) typé cela implique t il le le développeur doit passer son temps à vérifier le type ( ajouter du code ) lorsque cela est nécessaire selon le contexte ? si oui ..vive typescript ....
Le language non typé me fait penser à la gestion de la mémoire et du concept de "garbage collector" de java . Le concept de "garbage collector " a laisser le choix aux développeurs d'écrire ou non le code de la gestion de la mémoire !! et je pense que peu de développeur écrivent eux même leur gestionnaire de mémoire .Pourquoi s obliger à écrire son gestionnaire de typage et se compliquer le debug avec javascript ?
J'avais lu de développer ( pas pour javascript) c'est en temps en gros 30% d' écriture du code et 70% de temps à debuger !!! Qu'est ce que cela doit être avec javascript pour ceux qui écrivent les librairies et les Frameworks ( pas les intégrateurs qui les utilisent )

Merci
Modifié par 75lionel (10 Jun 2016 - 01:44)

75lionel a écrit :
ce post fait suite à celui ci dont je reprend le code javascript qui me pose des nouvelles questions ici .
J'essaie de faire attention au mots employés mais trop de choses implicites ou trop de contextes pour être précis compréhensible ....
NB ; les variables dans la console sont attaché a l onglet actif . Il faut fermer l onglet et réouvrir un nouveau onglet pour n'avoir aucune variables en mémoire .
NB le fait de copier plusieurs lignes de code javascript ( dans ce post) en une seule fois vers la console fait que la console vérifie la syntaxe et l'éxecute le code . si l'étape de la syntaxe et l'execution renvoie une erreur aucun code ne sera exécuté . Y a t il un moyen que la console exécute au moins les lignes qui sont exactes lors de la phase de vérification syntaxe et d'exécution ? ( cela me fait penser au comportement du code SQL )

function f (o) { o.c = 3; }
var num=new Number(3.14);
num // Number {[[PrimitiveValue]]: 3.14}
console.log(num.c); // undefined 
f(num); // undefined
console.log(num.c); //3
num.deux=2 //
num //  Number {c: 3, [[PrimitiveValue]]: 3.14}
num.c // 3 
num.texte="texte" // 
 // ne pas copier cette ligne lors du copier coller global des lignes dans la console 
num.deux * num.texte  //  NaN 
[

rien que cette exemple montre quelque chose d'étonnant : le type Number se comporte comme une liste de clé/valeur !!
Je me demande maintenant
1) comment accéder à la valeur 3.14 selon le contenu de num ?

num.[[PrimitiveValue]]   // Uncaught SyntaxError: Unexpected token
parseFloat(num.toString()) //est la solution  
num.valueOf() // est une autre solution  

donc puis je affirmer qu'une variable object de type number ne peu contenir qu une clé de type PrimitiveValue et que l'on accède à sa valeur par un moyen différent des autres clés/valeurs !!


primitive value me fait penser en CSS à un anonymous region ou en javascript à une fonction anonyme
Enfin un article à lire intéressant sur le concept de [[PrimitiveValue]]

2)Comment avoir acces à la valeur 3.14 dans le dernier object num ( plusieurs key/value)?

num[[[PrimitiveValue]]] //syntaxe bracket  ne fonctionne pas 
num."[[PrimitiveValue]]"   // syntax point ne fonctionne pas 
var vals = Object.keys(num).map(function (key) {
    return num[key];
});
 //si num retourne  Number {c: 3, deux: 2, texte: "texte", texte1: "texte1", [[PrimitiveValue]]: 3.14}
// alors vals contient  [3, 2, "texte", "texte1"] ou est passé 3.14 ??!!!
num1=  {c: 3, deux: 2, texte: "texte"} // Object {c: 3, deux: 2, texte: "texte"}  
 

[[PrimitiveValue]] n'a pas le comportement des clés : c , deux ,"texte" !!!

3) pourquoi javascript accepte

num.texte="texte" 
num //Number {texte: "texte", [[PrimitiveValue]]: 3.14}

Ou est l interêt d utiliser un type Number si le comportement est celui d 'un Object ?
1_ ) je pense que toutes saisie d'entrée ( ici clavier) est convertie en caractère ( uncode/ glyph) sur un GUI pour les humains et en nombre en interne pour la machine mais cela ne semble pas la raison ( voir 2_)
2_) La vérification du au type Number se fait a l appel ( par un code explicite coder par le dev) en sortie pas en entrée !!!
Du fait que javascript est faiblement ( pas) typé cela implique t il le le développeur doit passer son temps à vérifier le type ( ajouter du code ) lorsque cela est nécessaire selon le contexte ? si oui ..vive typescript ....
Le language non typé me fait penser à la gestion de la mémoire et du concept de "garbage collector" de java . Le concept de "garbage collector " a laisser le choix aux développeurs d'écrire ou non le code de la gestion de la mémoire !! et je pense que peu de développeur écrivent eux même leur gestionnaire de mémoire .Pourquoi s obliger à écrire son gestionnaire de typage et se compliquer le debug avec javascript ?
J'avais lu de développer ( pas pour javascript) c'est en temps en gros 30% d' écriture du code et 70% de temps à debuger !!! Qu'est ce que cela doit être avec javascript pour ceux qui écrivent les librairies et les Frameworks ( pas les intégrateurs qui les utilisent )

Merci

Non mais, franchement, à plusieurs reprises il t'a été demandé d'être clair et précis dans tes questions... et faut bien avouer que ça n'en prend pas le chemin.
C'est l'histoire d'un gars courant dans tous les sens et passant d'une idée à l'autre à vitesse supersonique. Même en y mettant de la bonne volonté, il devient difficile de suivre tes élucubrations, surtout que tu passes ton temps en questions / réponses décousues.
Je sais pas, mais prends ton temps, bois un coup ou fais une séance de yoga pour te calmer et après, mais après seulement, viens nous exposer de façon claire et structurée tes problèmes existentiels...
Pour en revenir à l'un de tes questionnements, du moins si j'ai bien compris ta prose, non le carnage collector ne laisse pas au programmeur le choix de gérer la mémoire... sa finalité étant justement tout le contraire, c'est à dire l'affranchir / lui interdire cette gestion.
J'ai commencé en Turbo Pascal et tout se jouait via des pointeurs qu'on allouait / libérait à la mano. Rigueur obligatoire, mais super performances... Java ne te laisse pas cette liberté = sécurité + lourdeur des traitements en arrière plan qui se déclenchent quand ils veulent et comme ils veulent.
C# est plus futé sue ce point puisqu'il t'autorise à laisser le carnage collector (mode par défaut) ou bien passer en mode Unsafe et gérer tes allocations / libérations de mémoire "à l'ancienne".
Si tu crées du code comportant des routines d'affichage à l'écran, une programmation par pointeurs hors garbage collector reste, de loin, la plus efficace.
Pour ce qui est de ton histoire de Number, typage des variables, je t'invite à revoir date date la formulation de ta question. Secoues toi la tête, histoire de tout remettre un peu d'aplomb, et reviens ensuite sur le forum avec l'esprit clair.
Tu connais la chanson : "Ce qui se conçoit bien..."

Foutue complétion de frappe au clavier sur smartphone...
Bien évidemment "date date" a remplacé "dare dare".
Quant au "carnage collector", pas fais exprès mais finalement je l'aime bien celui-ci...

a écrit :
1) comment accéder à la valeur 3.14 selon le contenu de num ?

Avec une des deux solutions que tu as toi-même trouvées. En principe valueOf.

a écrit :
donc puis je affirmer qu'une variable object de type number ne peu contenir qu une clé de type PrimitiveValue et que l'on accède à sa valeur par un moyen différent des autres clés/valeurs !!

primitive value me fait penser en CSS à un anonymous region ou en javascript à une fonction anonyme

Je ne vois pas le rapport ?

a écrit :
2)Comment avoir acces à la valeur 3.14 dans le dernier object num ( plusieurs key/value)?

Pareil, avec valueOf.

Tu n'as aucun moyen d'accéder à cette valeur autrement. Object.keys, Object.getOwnPropertyNames/Object.getOwnProperty , for...in, tous ces moyens échoueront et c'est normal, car la valeur 3.14 est intrinsèque à l'objet, elle n'est pas stockée dans le hashing des propriétés.

a écrit :
Ou est l interêt d utiliser un type Number si le comportement est celui d 'un Object ?

En pratique, l'intérêt est quasi nul. Ca reste principalement de la masturbation intellectuelle.

Tiens, si tu veux t'amuser avec un truc totalement inutile en ES6 :

class MyNum extends Number {
constructor (x) { super(x+1); }
valueOf () { return super.valueOf()+1; }
}


a = new MyNum(1); // 3
b = new MyNum(a+1); // 6
c = new MyNum(2*a + 3*b + 1); // 26

a écrit :
Le language non typé me fait penser à la gestion de la mémoire et du concept de "garbage collector" de java . Le concept de "garbage collector " a laisser le choix aux développeurs d'écrire ou non le code de la gestion de la mémoire !! et je pense que peu de développeur écrivent eux même leur gestionnaire de mémoire .Pourquoi s obliger à écrire son gestionnaire de typage et se compliquer le debug avec javascript ?

Le cheval blanc d'Henri IV a changé de couleur. Kamoulox ! Kamoulox !

a écrit :
J'avais lu de développer ( pas pour javascript) c'est en temps en gros 30% d' écriture du code et 70% de temps à debuger !!! Qu'est ce que cela doit être avec javascript pour ceux qui écrivent les librairies et les Frameworks ( pas les intégrateurs qui les utilisent )

JavaScript est pétri d'illogismes et de non-sens de toutes sortes. Mais c'est le cas pour la plupart des autres langages aussi. La norme ES6 tente de corriger un peu le tir.
Sans vouloir trop m'avancer, je pense que ces proportions sont assez juste pour à peu près tous les langages de programmation et tous les programmeurs du monde. Il est pratiquement impossible, et on l'a déjà démontré scientifiquement, d'écrire un code qui ne contient aucun bug; et surtout pas du premier coup.
Mème les meilleurs ou ceux qui sont supposé l'être introduisent des erreurs. Regarde les dernières failles majeures découvertes pour t'en convaincre: HTTPS (heartbleet), debian (et son 28 fois backspace qui te fait root), Apple (et son fameux break doublé dans son code pour HTTPS de nouveau, ou encore la mise à jour qui transformait les iPhone 5S en iPod...). IL paraît même que le code de lancement de l'arme nucléaire des USA a été pendant très longtemps 000000 dans les années 1970 (heureusement que les soviétiques ne l'ont jamais su !)
Il n'y a qu'un seul moyen, tester, débugger, retester, redébugger, encore et encore...

Tu trouveras bien des exemples sur le net qui démonteront tel ou tel langage point par point en démontrant tant ils contiennent d'incohérences. Les auteurs ont été particulièrement prolifiques concernant JavaScript, PHP et Java.

Quoi qu'on choisisse comme langage et comme environnement, c'est toujours facile de faire un mauvais code.
JE suis quand même d'avis que c'est moins facile dans les langages statiquement typés, mais c'est un point de vue.