Polyfill without clobbering?

[mikehall314]

I'm aware that I can call polyfill() to create global.Promise if it doesn't already exist, but messing with the global object makes me itchy, especially if my code isn't the only code running in the system. (e.g. some less responsible library puts an incompatible Promise implementation into the global object and I'm clobbering it, or it clobbers me).

Would it make sense for require("es6-promise").Promise to return the native implementation if it is available, and only return the RSVP-ish version if it isn't? That way I can cheerfully use var Promise = require("es6-promise").Promise; without worrying I'm going to glitch the system somewhere else.

[stefanpenner]

maybe pofyfill(optionalGlobalToPlacePromiseConstructor) ?

[mikehall314]

Is that preferable to simply returning a native Promise from require("es6-promise").Promise? At the moment, it always returns the RSVP-ish implementation, even when there is a compliant native implementation available. I'm struggling to think of why that might be desirable behaviour?

[stefanpenner]

@mikehall314 lets let @jakearchibald decide on this one. I can implement either quicky.

Also for reference no implementation is actually fully compliant as no browser version actually supports subclassing but es6-promise does. So in a strange (and unexpected way) require('es6-promise').Promise works as expected

@jakearchibald do we consider the lack of subclassing a criteria of polyfilling?

[stefanpenner]

@jakearchibald ping?

[jakearchibald]

I think subclassing is useful, so we should clobber in that case.

You can do var Promise = (self.Promise && !self.Promise.prototype.cast) ? self.Promise : require("es6-promise").Promise if you're happy without subclassing.

[stefanpenner]

kk