Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Treating null as undefined as well #4

Open
joepie91 opened this issue Oct 11, 2017 · 2 comments
Open

Treating null as undefined as well #4

joepie91 opened this issue Oct 11, 2017 · 2 comments

Comments

@joepie91
Copy link

joepie91 commented Oct 11, 2017

The following is a brief summary of a discussion that was had on IRC.

I feel that when considering whether something is 'defined', it should treat null in the same way as undefined; in the current proposal, it treats null as a defined value. Given the following points:

  1. It's undesirable to introduce two operators for the different cases ("only ignore undefined" vs. "ignore undefined and null"), as this would introduce confusion and possibly make it easy for readers to misinterpret what a given piece of code is doing.
  2. An "escape hatch" will be needed; either of the two cases needs to be representable, but only one of the cases can have an operator assigned to it. Therefore, the other case needs to have a different, reasonably ergonomic, non-operator representation.
  3. Operators are expensive to introduce (there are only a few possibilities in terms of characters used), and cheap to use (not a lot of work to read and write, and easily recognizable); therefore, the operator should be used for the common case. This maximizes the benefit that the developer gets from the use of a relatively scarce operator 'slot'.
  4. In the JavaScript ecosystem, the bulk of libraries treat null and undefined interchangeably; libraries often don't even document which they will return, some of them return either of them inconsistently, and so on. In practice, this means that as a consumer of third-party code, "handling null and undefined as equivalent" is a common case.
  5. It's extremely rare to run into cases where there is a meaningful technical distinction between null and undefined. In almost all cases where there is a distinction, either only one of them is ever used (but it could be either one), or the distinction is purely philosophical (eg. explicitly vs unintentionally empty value) and has no effect on real-world code that's written around it.

... it would seem logical to change the meaning of the ?| to include both null and undefined.

To rehash which cases this covers:

  • null and undefined used interchangeably (common): Covered.
  • Only null or only undefined used, but not both (common): Covered.
  • Philosophical difference between null and undefined, but no practical consequences (uncommon): Covered.
  • Meaningful technical difference between null and undefined, where both options need different treatment in consuming code (uncommon): Not covered.

This leaves the question of the 'escape hatch' - if a developer does need to express an explicit check for undefined that doesn't include null, how can they represent this? The obvious solution to this seems to be to use the proposed 'decider' mechanism (for which I have some separate suggestions for improvement).

@mk-pmb
Copy link
Owner

mk-pmb commented Oct 11, 2017

Thanks for summarizing! Everyone, feel free to vote on the suggestion with thumbs up/down emoji.

On the theoretical side, it might be nice to distinguish any existing property of a JSON container from a missing one, e.g.

let systemConfig = require('/etc/foo.json');
let localConfig  = require('./foo.cfg.json');
function worldsBestJsonValue() {
  v = (systemConfig.bestJsonValue ?| localConfig.bestJsonValue);
  if (v === undefined) { throw new Error('no idea'); }
  return v;
}

@mk-pmb
Copy link
Owner

mk-pmb commented Oct 13, 2017

Just found the Null Coalescing proposal. Link is now in the readme, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants