rtfeldman / seamless-immutable

Immutable data structures for JavaScript which are backwards-compatible with normal JS Arrays and Objects.
BSD 3-Clause "New" or "Revised" License
5.37k stars 195 forks source link

Consolidate development and production distributables. #90

Closed InsomniacFury closed 8 years ago

InsomniacFury commented 8 years ago

From what I can tell the only difference between development and production is

if ("development" !== "production") {
      // Make all mutating methods throw exceptions.
      for (var index in bannedMethods) {
        if (bannedMethods.hasOwnProperty(index)) {
          banProperty(obj, bannedMethods[index]);
        }
      }

      // Freeze it and return it.
      Object.freeze(obj);
    }

I think it would be less confusing to produce 1 set of artifacts, i.e.

./seamless-immutable.js
./seamless-immutable.min.js

where the constructor for immutable would effectively flag that behavior, e.g. whether to enforce immutability. Ideally avoiding the need for something like https://github.com/rtfeldman/seamless-immutable/pull/86 to clarify up front.

I would propose similar to merge(),

var  obj = Immutable( {}, {
  enforceImmutablity: [true|false]
} );

This would be backwards compatible interface-wise. The default value of enforceImmutablity is up for debate, but I would suggest it be true, so that anyone who is concerned about performance can specifically make the call. Or if performance is only a concern on a specific browser then that flag can be dynamically set based on user agent or something to that effect.

Thoughts?

rtfeldman commented 8 years ago

Appreciate the suggestion, but one of the design goals for seamless-immutable is to free yourself from worrying about whether anything you pass to Immutable will be mutated; it simply won't be. The production build being "all or nothing" means you should only use it when you're confident enforcement wouldn't have done anything anyway.

This change would make it so you'd instead have to start thinking about when enforcement applied on a case-by-case basis, and avoiding that is important to me.

Thanks for the idea, but I'm not open to changing the current behavior on this. :smile:

InsomniacFury commented 8 years ago

Cool, thanks for your consideration.