Pourquoi y a-t-il une valeur `null` en JavaScript?

https://stackoverflow.com/questions/461966

19-08-2019
|

Question

En JavaScript, il existe deux valeurs qui disent en gros "Je n'existe pas" - indéfini et null .

Une propriété à laquelle un programmeur n'a rien assigné sera indéfini , mais pour qu'une propriété devienne null , null doit être être explicitement attribué.

J'ai déjà pensé que null était nécessaire, car undefined était une valeur primitive et null un objet. Ce n'est pas le cas, même si typeof null donnera 'objet' : en fait, les deux sont des valeurs primitives - ce qui ne signifie ni undefined ni null peut être renvoyé par une fonction constructeur, car les deux seront convertis en un objet vide (il faut générer une erreur pour proclamer un échec dans les constructeurs).

Ils évaluent également false dans des contextes booléens. La seule différence réelle à laquelle je puisse penser est que l’une s’évalue à NaN , l’autre à 0 dans des contextes numériques.

Alors pourquoi existe-t-il à la fois undefined et null si cela confond simplement les programmeurs qui vérifient de manière incorrecte null lorsqu’ils tentent de savoir si la propriété a été définie ou non?

Ce que j'aimerais savoir, c'est si quelqu'un a un exemple raisonnable dans lequel il est nécessaire d'utiliser null , ce qui ne pourrait pas être exprimé avec undefined à la place.

Donc, de l'avis général, undefined signifie "il n'y a pas de telle propriété" alors que null signifie "la propriété existe, mais ne contient aucune valeur".

Je pourrais vivre avec cela si les implémentations JavaScript appliquaient effectivement ce comportement - mais undefined est une valeur primitive parfaitement valide, de sorte qu'il peut facilement être affecté à des propriétés existantes pour rompre ce contrat. Par conséquent, si vous voulez vous assurer qu'une propriété existe, vous devez quand même utiliser l'opérateur dans ou hasOwnProperty () . Encore une fois: quelle est l’utilité pratique de séparer les valeurs de undefined et de null ?

J'utilise réellement undefined lorsque je souhaite supprimer les valeurs des propriétés qui ne sont plus utilisées mais que je ne souhaite pas supprimer . Devrais-je utiliser null à la place?

La solution

La question n'est pas vraiment "Pourquoi y a-t-il une valeur nulle dans JS &"; - il existe une valeur nulle dans la plupart des langues et est généralement considérée comme très utile.

La question est de savoir "pourquoi existe-t-il une valeur indéfinie dans JS"? Principaux endroits où il est utilisé:

lorsque vous déclarez 'var x;' mais ne lui attribuez pas, x est indéfini;
lorsque votre fonction reçoit moins d'arguments qu'elle n'en déclare;
lorsque vous accédez à une propriété d'objet non existante.

'null' aurait certainement aussi bien fonctionné pour (1) et (2) *. (3) devrait vraiment lancer immédiatement une exception, et le fait qu’elle ne le fasse pas, renvoyant à la place cet étrange 'indéfini' qui échouera ultérieurement, est une source importante de problèmes de débogage.

*: vous pouvez également soutenir que (2) devrait générer une exception, mais vous devrez alors fournir un mécanisme plus explicite et mieux explicite pour les arguments par défaut / variables.

Toutefois, à l'origine, JavaScript ne comportait pas d'exception ni aucun moyen de demander à un objet s'il avait un membre sous un certain nom - le seul moyen était (et reste parfois) d'accéder au membre et de voir ce que vous obtenez. Étant donné que 'null' avait déjà un but et que vous souhaitiez peut-être lui affecter un membre, une valeur hors bande différente était requise. Nous avons donc "indéfini", c'est problématique, comme vous l'avez fait remarquer, et c'est une autre "fonctionnalité" JavaScript remarquable que nous ne pourrons jamais nous débarrasser.

J'utilise en fait undefined lorsque je souhaite supprimer les valeurs des propriétés qui ne sont plus utilisées mais que je ne souhaite pas supprimer. Dois-je utiliser null à la place?

Oui. Conservez 'indéfini' en tant que valeur spéciale pour signaler lorsque d'autres langues peuvent générer une exception.

"null" est généralement préférable, sauf sur certaines interfaces DOM IE où la définition de "null" peut vous donner une erreur. Dans ce cas, la définition de la chaîne vide a souvent tendance à fonctionner.

Autres conseils

décrit , mais en résumé:

undefined est l’absence de type et de valeur et null est l’absence de valeur.

De plus, si vous faites des comparaisons simples, vous aurez raison, elles se ressemblent. Mais essayez ===, qui compare le type et la valeur, et vous remarquerez la différence.

Je ne pense pas qu'il y ait de raison d'avoir à la fois null et undefined , car c'est la seule raison pour laquelle de nombreuses personnes ont suggéré (& undefined signifie que cette variable / propriété ") n'est pas valide, du moins en JavaScript. undefined ne peut pas vous dire si la variable / propriété existe ou non.

console.log(foo);               // "ReferenceError: foo is not defined"
                                // foo does not exist
var foo;
console.log(foo);               // "undefined", a different response
console.log(foo === undefined); // "true", but it does exist

var obj = {};
console.log(obj.hasOwnProperty("foo")); // "false", no such property
obj.foo = undefined;
console.log(obj.hasOwnProperty("foo")); // "true", it exists and has the value "undefined"
console.log(obj.foo === undefined);     // "true", but it does exist

obj.bar = "delete me";
obj.bar = undefined;
console.log(obj.hasOwnProperty("bar")); // "true", not actually deleted
delete obj.bar;
console.log(obj.hasOwnProperty("bar")); // "false", deleted

Comme vous pouvez le constater, la vérification de foo === undefined ne vous indique pas si foo existe et le paramétrage de obj.bar = undefined ne supprime pas réellement la barre .

L'intention initiale de l'auteur de JavaScript peut être que undefined représente "non-existence". Cependant, la mise en œuvre ne s’est pas avérée ainsi.

Il est tout à fait possible d’avoir besoin des deux. Par exemple, si vous interrogez WMI, il est tout à fait possible qu'une classe renvoie des propriétés qui ont une valeur null. Ils sont définis, ils ont juste la valeur null à ce moment-là.

Je pense que votre conclusion selon laquelle JavaScript définit non défini comme étant "il n'y a pas une telle propriété" et null , car "la propriété n'a pas de valeur". est parfaitement correct. Et dans un langage aussi dynamique que JavaScript, il s'agit d'une distinction très importante. L'utilisation de la frappe de canard signifie que nous devons être en mesure de différencier une propriété qui n'existe pas et qui n'a pas de valeur. C'est notre principal moyen de dériver des informations de type. dans un langage à typage statique, il existe une distinction nette entre un champ nul et un champ inexistant. En JavaScript, ce n'est pas différent. Cependant, il est vérifié au moment de l'exécution et peut être modifié jusque-là.

Je vais devoir convenir que la mise en œuvre est étrange, car la distinction est souvent floue. Cependant, je pense qu'en JavaScript la distinction est importante. Et pouvoir attribuer undefined est essentiel.

Je me souviens avoir lu un billet de blog il y a quelque temps sur un RPG en ligne écrit en JavaScript. Il a utilisé des exemples dans lesquels des objets étaient créés en tant que copies d'instances existantes plutôt que des prototypes (classes, fonctions, etc.), puis modifiés. Cela m'a vraiment fait comprendre à quel point non défini pouvait être puissant lors de la modification d'objets existants, mais je ne me souviens plus qui l'a écrit.

sémantiquement, ils signifient différentes choses. Le type null a exactement une valeur dans son domaine, null et une propriété peut être affectée à cette valeur spécifique. Undefined représente un manque distinct de toute valeur attribuée.

En tant que programmeur Java, je vois une énorme différence entre undefined et null. Codage de JavaScript, pas tellement, parce que JavaScript n'est pas fortement typé, et les différences entre undefined et null sont estompées par les conversions automatiques qui sont fréquemment effectuées par l'exécution. BTW, je profite souvent de ces conversions; ils rendent mon code JS plus compact et lisible.

Pour répondre à votre question, non défini signifie qu'une valeur n'a jamais été définie. En pratique, cela pointe généralement vers un bug. Si votre propriété d'objet n'est pas définie, cela signifie que vous n'avez pas défini la propriété pour une raison quelconque, ou que je recherche quelque chose qui n'existe pas du tout. C’est un véritable problème lorsque vous travaillez sur un projet avec plusieurs codeurs.

null signifie que " no value " était explicitement défini. Concrètement, vous me parlez de la propriété, peut-être qu’elle n’est pas utilisée dans ce contexte ou qu’une valeur n’a pas encore été déterminée.

En Java, toute tentative d'accès à un champ non défini entraînera toujours une exception. En fait, le compilateur peut vous avertir dans votre code.

Essayez cet exemple:

<html>
<head>
    <script type="text/javascript">
        function ShowObjProperties(obj) {
            var property, propCollection = "";

            for(property in obj) {
                propCollection += (property + ": " + obj[property] + "\n");
            }

            alert(propCollection);
        }

        var obj = {
            userid: 3,
            name: 'me!',
            speak: function() { alert('Hi! My name is ' + this.name + ' and my ID is ' + this.userid + '.'); }
        }

        //Shows all properties
        ShowObjProperties(obj);

        //The Speak function is no longer in the list!
        delete obj.speak;
        alert(typeof obj.speak);
        ShowObjProperties(obj);

        //The UserID is still listed, it just has no value!
        obj.userid = null;
        ShowObjProperties(obj);
    </script>
</head>
<body>

</body>
</html>

Je pense qu'il existe une utilisation très réelle de 2 types différents ici.

Il s’agit de la nature dynamique javascript.

Les éléments peuvent ne pas être définis pour pouvoir être ajoutés ultérieurement. C’est sans doute pourquoi le javascript est si puissant et extensible.

c’est une fonctionnalité linguistique importante si vous programmez votre programme autour du paradigme du javascript.

// a key exists as a placeholder for something
if(obj[name] === null) 
// no key exists int eh hashtable that is in this object
if(obj[name] === undefined)

Ceci est très utile si vous traitez avec un ensemble de données nécessitant une valeur représentant rien, indiquant une action différente de l'utilisation de "rien" pour indiquer l'action par défaut.

filter_func_pt = {
  date:function(d){ return Math.round(d.getTime()/1000);},
  user: null,
}

function transform(obj){
    var ret = {};
    for( var prop in obj){
       var f = filter_func_pt[prop];
       if(f)
          ret[prop] = f(obj);
       else if(filter_func_pt[prop] === null)
         continue;
       else
         ret[prop] == obj;
    }
  return ret;
}

var a = {
   date: new Date(),
   user: 'sam'
   votes: [23, 41, 55] 
};

var b = transform(a);

/* b = {
 *    date: 1298582417
 *    votes: [23, 41, 55]
 * }
 */

dans le code ci-dessus, le mot-clé null et le serveur undefined ont des objectifs très clairs et différents. la recherche non trouvée dans l'objet filter_func_pt qui retourne undefined signifie d'ajouter la propriété à l'objet retourné telle quelle, alors qu'une valeur null indique que la valeur doit être masquée , et non ajouté, et la présence de toute valeur vraie dans ce cas représente une fonction utilisée pour transformer la valeur avant de l’ajouter à l’objet ret .

null is beautiful

comme tous les autres types de scripts en direct.

cite: En JavaScript, il y a deux valeurs qui disent "je ne le fais pas" exist '- indéfini et null.

Pourquoi voudriez-vous dire des choses incorrectes?!

"null" est un "objet vide" exactement comme "0". est un "numéro vide" . 0, n'est rien, même s'il existe en tant que type d'un nombre. null est bien sûr également vide, mais "c’est" et c'est une chose bien définie d'un type d'objet .

Il est courant de parler de ces "types", quand ils ne le sont pas. En fait, ce sont des "catégories". Mais c'est fini maintenant.

Nous allons donc nous en tenir à dire que " null " est un type d'objet sans sorte. Et " null " dit "j’existe beaucoup [!], mais je n’ai pas le contenu de mon espèce".

Alors que undefined ne contient ni le type ni le type, undefined étant également sa définition de type. Un type indéfini d'un type devient sa typologie distinctive. Une sorte de [ne fait "rien") existe et comment définissez-vous la question "rien".

cite: undefined ni null peuvent être retournés à partir d'une fonction constructeur, comme les deux seront convertis en un objet vide

Vous avez encore réussi à dire une chose incorrecte. Bien sûr que non, le "non défini" n'est pas un objet, c'est un jeton simple que nous, les humains, comprenons; mais contrairement à cela, null est - et il vous dit que: son type est correct, mais le type que vous recherchez ne figure pas dans celui-ci, ou du moins, pas pour le moment. Venez nous rendre visite plus tard quand nous y avons mis \ assigner un objet.

cite: La seule différence réelle à laquelle je peux penser est que l’on évalue NaN, l’autre à 0 dans les contextes numériques.

Cela fait l’essentiel de leur distinction fondamentale, comme il a été mentionné: indéfini est un gage simple et, dans la mesure où il se compose du même matériel "génétique" que ses parents distants: les chaînes, le [ + undefined], l'opération sera convertie en NaN, de même null, bien sûr, elle se transformera en un type correct, 0 \ Number, et contrairement à undefined qui se transformera en une chaîne (! pas vide!) et c’est exactement pourquoi il génère à la place NaN . Où: + non défini > > + " non défini " > > NaN. Étant donné que le contexte numérique attend une valeur explicite.

Alors que le contexte booléen attend une référence - ne trouve rien à convertir et renvoie "faux".

Coupons court maintenant ...

cite: Encore une fois: quelle est l’usage pratique de valeurs distinctes pour indéfini et nul?

Je vais essayer de vous donner seulement deux exemples empiriques et j'espère suffire

oElement.onclick >> null

// signifie -la propriété existe; sa valeur attendue est de type: Object et oElement prend en charge l'option "onclick". événement!

oElement.innerText >> ""

// signifie - la propriété existe; sa valeur attendue est de type: chaîne , ce qui signifie que oElement prend en charge le texte "innerText". propriété.

dans les deux cas, si vous recevez " undefined " cela signifie que la propriété n'existe pas; n'est pas pris en charge ou a une implémentation incorrecte (fournisseur).

Restez gelée et amusez-vous.

après avoir lu une discussion incroyable sur undefined vs null, peu de recherches sur Google m'ont amené à Mozilla Documentations https://developer.mozilla.org/en- US / docs / Web / JavaScript / Référence / Global_Objects / null il est mentionné - null est souvent récupéré à un endroit où un objet peut être attendu mais aucun objet n'est pertinent.

N'est pas similaire au motif d'objet Null https://en.wikipedia.org/wiki/Null_object_pattern

Donc, je suppose que cela a du sens d'avoir le type de données Null.

La documentation est également mentionnée comme typeof null // " objet " (non "null" pour des raisons d'héritage)

Je ne sais pas quelles sont les raisons héritées

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow