Repository navigation
Introduce the Nil Object #136
Description
Activity
@greelgorke I think this is backwards, the problem here is with the streams API not allowing
nullin some scenarios. Fix that and your problem goes away. Having to write a load of extra guards againstNilandnullandundefinedthoughout the codebase would be terrible.I think this pain point is covered in #89. I was of the same mind re: adding a sentinel value to serve as EOF for readable streams, but I've since come around to the whatwg/streams-style of using a separate function from push to denote "closing" a stream. It is unlikely that we will take the sentinel object approach in enhancing streams in the future.
- added a commit that references this issue
on Oct 9, 2016
Hello and sorry in advance for all typos!
I'd like to introduce a new Object in the core, which consistently represents a null value but is not
null. Why is this interesting?One of the main pain points in Streams (not just core) is that
nullisn't a good choice for end-of-stream value in object mode. Highland.js resolves it with it's own _.nil value. But this works fine only for the same install. as soon as we have two dependencies, each having it's local highland dependencies, the _.nil check is flawed. a central instance would solve some pains here.why core? it's the single point of truth in Node.js context. This value could also provide more interoperability to different user-land packages.