Subclassing about promise-polyfill HOT 7 CLOSED

Hey Joe! That is a great idea. I think we should create a safe then function along the lines of this. If you create a pull request, I will definitely accept it. Please add tests as well.

from promise-polyfill.

Will do later today, thanks!

from promise-polyfill.

@benderTheCrime Have you had time to work on this? I think this would be a useful feature. If not, I can work on it.

from promise-polyfill.

I'm sorry. I forgot about this altogether. If you have time to work on it that would be great. Otherwise, I can work on it during the week.

from promise-polyfill.

Here is a first pass at this: #27

I say first pass because I did not see the advantage of defining the safeThen once I got down to it. I don't know that all of the work that the safeThen method does is necessary to ensure that the Promise that is being resolved is actually a Promise and not an instance of the subclass.

SO I started with safeThen, and then pulled out the handle and the creation of the new Promise, and then changed the method to safeCtor, and then moved that into then, and then realized that that is where I started in the first place.

Any user subclassing this should be able to use it in such a way that prevents augmentation to any of the private properties created (or at least know when they've broken something sufficiently to backpedal and undo the changes they've made). With this consideration in mind, we prevent ourselves from adding too much code for this functionality.

I can still add the safeThen if you want. At the end of the day i'm not too fussed about it and it's your preference.

Also, let me know if the tests added are sufficient. They are pretty basic in comparison to the extent to which the rest of the library is tested.

from promise-polyfill.

This is completed in #27.

from promise-polyfill.

Thanks!

from promise-polyfill.