Repository navigation
Introduce the Nil Object #136
Description
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 null isn'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.
Activity
phpnode commentedon Dec 10, 2014
@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.chrisdickinson commentedon Dec 17, 2014
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.
Fix narrowing to a stream by touching it in message lists.