Closed hughfdjackson closed 11 years ago
For the record, .immutable
was preferred because it didn't rely on object identity - which can be a tricky situation when you have a system like NPM that will allow the system to use multiple versions of the same library.
If an immutable object is passed back by library N, then querying it via a directly required instance of immutable
should work.
Why do you need this flag?
To provide a slightly less duck-typy way to deal with mixed immutable and 'regular' objects - for instance, for a deep get that might (not decided yet) include both mutable and immutable objects:
and, ofc, because npm breaks instanceof as a universal checker - as you demonstrated so amply before with your prototypes problem.
Functions that deal with mixed immutable and 'regular' objects
are very expensive in terms of additional complexity.
Avoid it if you can.
You may well be right - still undecided on how deep operations should work. That said, sometimes important to know if something's claiming to be (for instance) a promise, or is some other type of return value.
I think this flag will find its place in making it easy to reason about these objects 'in the wild' (when more than one lib exports them). I'll freely admit it's a slight API gamble; but erring slightly more on the side of making it easy for people to integrate into their daily lives doesn't seem like a step too far.
I prefer x.type === "immutable@Immutable
for that kind of stuff, but sure
Flag or function to show that an immutable value is immutable:
Suggestions:
Pros:
Cons:
Pros:
Cons: