Remove collections dependency and es6-set instead #131
Conversation
faridnsh
force-pushed
the
remove-collections
branch
2 times, most recently
from
c58d9b5
to
e617577
Compare
| if (Object.has(keys, method)) { | ||
| return Object.get(methods, method)(request); | ||
| if (keys.indexOf(method) !== -1) { | ||
| return methods[method](request); |
There was a problem hiding this comment.
O(n) vs O(1). Let’s use Object.prototype.hasOwnProperty.call.
There was a problem hiding this comment.
And one less line... Fixed it :)
|
With version 2 of Collections, I’m moving away from shims in favor of polymorphic operators (e.g., pop-swap, pop-equals, pop-compare). Q-IO version 2 already depends on Collections, although the change is incomplete. It makes me sad for Q-IO v1 to diverge, but this does seem like a sensible change. |
Since [collections module][1] modifies native objects, it's only good to be used as a top dependency of an application and not modules that it's using. The problem is that this will conflict if native objects has been modified by another module, let's say something like [sugar][2] or just another version of collections. When you have two of these being used in your app, you might be in trouble, where some code depends on a behaviour of a method implemented by one module but actually the method had been silently overriden by another module having a different behaviour. [1]: http://collectionsjs.com [2]: http://sugarjs.com
faridnsh
force-pushed
the
remove-collections
branch
from
e617577
to
cb9351c
Compare
|
+1 merge pls |
|
Adding @hthetiot as a collaborator. Send me your npm handle and I'll grant you publish as well. |
|
@alFReD-NSH Can you rebase ? |
|
Thanks @alFReD-NSH for great work. Feel free to re-open this PR with more changes if needed, in the meantime we may merge #168 |
Since collections module modifies native objects, it's only good
to be used as a top dependency of an application and not modules that
it's using.
The problem is that this will conflict if native objects has been
modified by another module, let's say something like sugar or just
another version of collections. When you have two of these being used in
your app, you might be in trouble, where some code depends on a
behaviour of a method implemented by one module but actually the method
had been silently overriden by another module having a different
behaviour.