New ask Hacker News story: Ask HN: Should scripting engines distinguish between "null" and "undefined"?
Ask HN: Should scripting engines distinguish between "null" and "undefined"?
3 by sgbeal | 4 comments on Hacker News.
i'm working on porting my language-agnostic scripting engine[^1] from C to C++ and i have a small conundrum: Do scripting languages really need both "null" and "undefined" values? i have long liked that JavaScript provides both "null" and "undefined", and have modeled my scripting languages after that since tinkering with them first became a hobby (right at 20 years ago). In the C++ rewrite, however, having both null and undefined would be slightly awkward, in exactly one of the two would require non-NULL (as in C++ nullptr) value, and that just feels odd. The simplest solution to this is to consolidate undefined/null into the same conceptual non-value and leave it at that. The more complex solution is to make one or the other of them a full-fledged value, with its own memory address, which seems somewhat counter-intuitive. (In this project's C predecessor[^1], both null and undefined have distinct C addresses, and that works well within that framework. It works _less well_ within the rewrite's framework, where _one_ of them will fit quite nicely but the other will require some shoehorning and special-casing). One of the inspirations for this rewrite is my recent first-time work with the Java Native Interface (JNI), which treats a Java null as a C NULL. That initially bugged me, but in practice it's more comfortable than having a distinct C value representing a Java null. In Java, however, null also fills the roll of "undefined," whereas JavaScript has both (and i rather _like_ that, as the distinction is occasionally relevant and/or interesting... but also doesn't seem game-breaking if they're combined into one concept). What say you, dear internet, on the matter of having separate "null" and "undefined" values? Yes? No? It depends? (On what does it depend?) PS: suggestions that it instead be rewritten in Rust will be tactfully ignored. [^1]: the being-rewritten project is: https://ift.tt/5i0IaWF
3 by sgbeal | 4 comments on Hacker News.
i'm working on porting my language-agnostic scripting engine[^1] from C to C++ and i have a small conundrum: Do scripting languages really need both "null" and "undefined" values? i have long liked that JavaScript provides both "null" and "undefined", and have modeled my scripting languages after that since tinkering with them first became a hobby (right at 20 years ago). In the C++ rewrite, however, having both null and undefined would be slightly awkward, in exactly one of the two would require non-NULL (as in C++ nullptr) value, and that just feels odd. The simplest solution to this is to consolidate undefined/null into the same conceptual non-value and leave it at that. The more complex solution is to make one or the other of them a full-fledged value, with its own memory address, which seems somewhat counter-intuitive. (In this project's C predecessor[^1], both null and undefined have distinct C addresses, and that works well within that framework. It works _less well_ within the rewrite's framework, where _one_ of them will fit quite nicely but the other will require some shoehorning and special-casing). One of the inspirations for this rewrite is my recent first-time work with the Java Native Interface (JNI), which treats a Java null as a C NULL. That initially bugged me, but in practice it's more comfortable than having a distinct C value representing a Java null. In Java, however, null also fills the roll of "undefined," whereas JavaScript has both (and i rather _like_ that, as the distinction is occasionally relevant and/or interesting... but also doesn't seem game-breaking if they're combined into one concept). What say you, dear internet, on the matter of having separate "null" and "undefined" values? Yes? No? It depends? (On what does it depend?) PS: suggestions that it instead be rewritten in Rust will be tactfully ignored. [^1]: the being-rewritten project is: https://ift.tt/5i0IaWF
Comments
Post a Comment