Added synchronous methods and tests

[johnhaley81]

This is in reference to fixing #58.

[edef1c]

Other than the stray debugger statement, this code looks pretty good to me.
That's independent from whether we want this functionality, however.
Personally, I think this would be convenient to have, but a bad fit for our goal of being a minimal Promise/A+ implementation.

[johnhaley81]

Yes, I thought about adding this in as a extension as well but it seems like I'd have to edit the prototypes of the object so at that point it seemed to be a better fit to add it into the core library.

[ForbesLindesay]

I'm really not sure about this functionality. I remember when I was starting out with using promises and I thought I wanted this all the time, but in reality I just haven't really needed it. I'm not adverse to it being something we make "possible" but I don't want it to be something that becomes available to new comers by default. I'm also wary of the fact that it would prevent us from publishing the minimal Promises/A+ implementation (currently require('promise/lib/core')) and the pure ES6 polyfill (currently require('promise/lib/es6-extensions')). I see the ES6 polyfil as an absolutely essential requirement and it must not have any additional methods or properties added to it.

If we could find some way to do this via a plugin, we could consider it. Perhaps behind some kind of flag so you could do require('promise/lib/sync').enable() and it could flip a feature flag or something.

[johnhaley81]

Currently the implementation hides all of the values that the extension library would need via closure scope.

I think I tried having my original extension use a promise to set the values that a user could then synchronously poll but there were issues with that. It was awhile ago so I don't remember the specifics but I do remember some unit tests were falling.

I could pursue that avenue again if we want to keep this library as bare bones as possible.

As far as the use case, I'm using this functionality to poll the promise in a C library thread to get the result and send it off to another JavaScript callback.

[edef1c]

Regarding your use-case: you can't mess with JS objects on another thread like that. V8 isn't thread-safe. You need to do these things from the JS thread.

[johnhaley81]

Correct. That specific code executes on the JavaScript thread and communicates back data via a baton object that's designed to hold any relevant data.

[johnhaley81]

Any further thoughts on this? Merge or close?

[ForbesLindesay]

This should now be possible to re-build based on just the _ prefixed properties, which would allow it to be made into an optional (disabled by default) plugin, which I would accept.

[johnhaley81]

Excellent! I'll get that going. Great progress on this repo guys!