Make Promiz.js Promise/A+ compatible

[RubenVerborgh]

As discussed in #1, Promiz.js should either pass the Promise/A+ spec or state in its README that it's not compatible with it, as to avoid confusion.

[Zolmeister]

See note: "The promise chain will try to run synchronously if possible (technically this breaks spec, but it's much faster and so worth it)" which address some (not all) of the issues

[RubenVerborgh]

That note is only one part; many other parts are failing. But please don't advertise spec compatibility, this really confuses people. Not even 30% of the spec is implemented at the moment. Also, the spec has chosen asynchronous completion for a reason.

[RubenVerborgh]

The following code shows a case where Promiz.js writes undefined because of synchronous completion, whereas spec-compatible Promise implementations correctly write result:

var Promiz = require('promiz');

function test() {
  var result, deferred = Promiz.defer();
  deferred.resolve();
  deferred.then(function () { console.log(result); });
  result = 'result';
}

test();

[Zolmeister]

I appreciate the concern, but I'm not here to rant about why I chose to ignore that part of the spec. The bottom line is that it is a huge detriment to performance, and I have never had issues arise in real-world code because of the synchronous resolution.

[RubenVerborgh]

Certainly not questioning your why; just questioning the "spec-compatible" label. "Spec-compatible" means that we could use Promiz.js instead of any of the other libraries; we cannot.

[Zolmeister]

@RubenVerborgh I'm sorry, you are 100% correct, and please forgive my rudeness (it was 5am!).

I have re-written Promiz core to be spec compliant, and additionally, I have added a new module promiz.micro which is my attempt to create the smallest spec library around (using what I wrote for Promiz core anyways).

Currently it's smaller than https://github.com/RubenVerborgh/promiscuous, so let's see what you can do :smile:

[RubenVerborgh]

@Zolmeister I'm deeply impressed, especially given the short timeframe in which you accomplished this. I have to take the challenge now :smile:

[RubenVerborgh]

Actually, there's nothing to do for me… what you have is just minimal. My whole implementation is based on not keeping explicit state; yours does but in a very smart way. No point in trying to beat that. I might have some suggestions that I'll submit later. But most of all, I need to update my blog post now :smile:

BTW, TypeError() is a very cool find, I had no idea that native constructors worked new-lessly.