Should we freeze(when)? #41

Closed
briancavalier opened this Issue May 17, 2012 · 7 comments

Comments

Projects
None yet
2 participants
@briancavalier
Member

briancavalier commented May 17, 2012

For a library like when, that needs to be trusted, defend against other, potentially non-compliant or even broken implementations, and may be in use by other 3rd party libs you're using in your application, it seems like a good thing. For example, you may have a single copy of when.js in your codebase, and it is being used by several of your dependencies.

In that case, you need to be able to trust that when.js hasn't been altered.

The tradeoff, of course, is that you can't do crazy stuff like replace when.defer() to make it do something you think it should be doing, or hang new functionality off of when. In my personal opinion, you shouldn't be doing those things anyway--imho, wrapping rather than replacing is a better option.

So, at least right now, I think we should freeze(when), but I'm definitely open to hearing what other folks think.

@jamietre

This comment has been minimized.

Show comment Hide comment
@jamietre

jamietre Jun 7, 2012

Even though I use a hacked version of when for my iqtest project (which we talked about a bit) I support this. I recently started including when in another public project and out of concern for possible conflicting implementations (like, my own!), I didn't just drop it in, but put it into that project's private namespace. This is not efficient and also means I have to do some extra work when updating it. It would be nice to not have to worry about this.

I think if you want to do crazy stuff like I did, then go ahead, but fork it and don't use the same namespace. We should be able to depend on the correct code being available in the global namespace.

jamietre commented Jun 7, 2012

Even though I use a hacked version of when for my iqtest project (which we talked about a bit) I support this. I recently started including when in another public project and out of concern for possible conflicting implementations (like, my own!), I didn't just drop it in, but put it into that project's private namespace. This is not efficient and also means I have to do some extra work when updating it. It would be nice to not have to worry about this.

I think if you want to do crazy stuff like I did, then go ahead, but fork it and don't use the same namespace. We should be able to depend on the correct code being available in the global namespace.

@briancavalier

This comment has been minimized.

Show comment Hide comment
@briancavalier

briancavalier Jun 7, 2012

Member

Thanks, Jamie. Those are my thoughts exactly.

Member

briancavalier commented Jun 7, 2012

Thanks, Jamie. Those are my thoughts exactly.

@briancavalier

This comment has been minimized.

Show comment Hide comment
@briancavalier

briancavalier Jun 8, 2012

Member

I'm pretty much convinced this is the right thing, so I'm scheduling it for 2.0. It's implemented in the dev-20 branch, so you can try it there. It shouldn't cause any problems unless you're doing sneaky things like hanging things off of when or replacing its methods. Like @jamietre said, if you're doing those things, you should fork it, or write a wrapper.

Member

briancavalier commented Jun 8, 2012

I'm pretty much convinced this is the right thing, so I'm scheduling it for 2.0. It's implemented in the dev-20 branch, so you can try it there. It shouldn't cause any problems unless you're doing sneaky things like hanging things off of when or replacing its methods. Like @jamietre said, if you're doing those things, you should fork it, or write a wrapper.

@briancavalier

This comment has been minimized.

Show comment Hide comment
@briancavalier

briancavalier Jun 22, 2012

Member

when is frozen in the dev branch now.

Member

briancavalier commented Jun 22, 2012

when is frozen in the dev branch now.

@briancavalier briancavalier reopened this Jul 25, 2012

@briancavalier

This comment has been minimized.

Show comment Hide comment
@briancavalier

briancavalier Jul 25, 2012

Member

Reopening for now, since we'll be doing at least one more release of 1.x before we go to 2.0, and we'll freeze(when) for 2.0.

Member

briancavalier commented Jul 25, 2012

Reopening for now, since we'll be doing at least one more release of 1.x before we go to 2.0, and we'll freeze(when) for 2.0.

@briancavalier

This comment has been minimized.

Show comment Hide comment
@briancavalier

briancavalier Oct 27, 2012

Member

For now, this is off the table. See #61 for more info. Once the v8 perf problem is fixed, we'll revisit.

Member

briancavalier commented Oct 27, 2012

For now, this is off the table. See #61 for more info. Once the v8 perf problem is fixed, we'll revisit.

@briancavalier

This comment has been minimized.

Show comment Hide comment
@briancavalier

briancavalier Jan 17, 2014

Member

I don't really feel strongly enough about this anymore to keep it open. If we find a compelling reason, we can reopen.

Member

briancavalier commented Jan 17, 2014

I don't really feel strongly enough about this anymore to keep it open. If we find a compelling reason, we can reopen.

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