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

Flag to indicate that the object is immutable #29

Closed
hughfdjackson opened this issue Apr 22, 2013 · 7 comments
Closed

Flag to indicate that the object is immutable #29

hughfdjackson opened this issue Apr 22, 2013 · 7 comments

Comments

@hughfdjackson
Copy link
Owner

Flag or function to show that an immutable value is immutable:

Suggestions:

var o = im.object()
o.immutable //= true

Pros:

  • simple
  • terse

Cons:

  • Not unique to immutable objects of this library
var o = im.object()
im.isImmutable(o) //= true

Pros:

  • unique to immutable objects of this library (potentially)

Cons:

  • Bit clunky
@hughfdjackson
Copy link
Owner Author

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.

@Raynos
Copy link

Raynos commented May 5, 2013

Why do you need this flag?

@hughfdjackson
Copy link
Owner Author

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:

@hughfdjackson
Copy link
Owner Author

and, ofc, because npm breaks instanceof as a universal checker - as you demonstrated so amply before with your prototypes problem.

@Raynos
Copy link

Raynos commented May 5, 2013

Functions that deal with mixed immutable and 'regular' objects are very expensive in terms of additional complexity.

Avoid it if you can.

@hughfdjackson
Copy link
Owner Author

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.

@Raynos
Copy link

Raynos commented May 5, 2013

I prefer x.type === "immutable@Immutable for that kind of stuff, but sure

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

No branches or pull requests

2 participants