Isolate m.prop() and m.deferred() implementations (mostly)

[dead-claudia]

This mostly isolates the implementations for both of these. Now, everything
here calls the method itself, not any of the external methods.

Few driveby fixes as well:

1. Git now ignores archive/ again (it's a build artifact, and can be removed
   when updating master)
2. Since I had to rewrite most of the Deferred implementation, the new version
   passes one of the skipped tests, so it is now enabled.

Prepares for #800.

[Naddiseo]

@IMPinball, what are the performance implications of this?

[dead-claudia]

About the same. The bottleneck is still in the rendering, which probably
needs rewritten to reduce GC pressure.

On Fri, Nov 20, 2015, 11:50 Richard Eames notifications@github.com wrote:

@IMPinball https://github.com/impinball, what are the performance
implications of this?

—
Reply to this email directly or view it on GitHub
#853 (comment).

[dead-claudia]

Promises should be slightly faster, but I haven't benchmarked it much.

On Fri, Nov 20, 2015, 19:16 Isiah Meadows impinball@gmail.com wrote:

About the same. The bottleneck is still in the rendering, which probably
needs rewritten to reduce GC pressure.

On Fri, Nov 20, 2015, 11:50 Richard Eames notifications@github.com
wrote:

@IMPinball https://github.com/impinball, what are the performance
implications of this?

—
Reply to this email directly or view it on GitHub
#853 (comment).

[dead-claudia]

I would also like to note that this is slightly breaking. m.prop() no longer returns a Mithril promise when wrapping a third-party promise, which could break those depending on this behavior.

[barneycarroll]

That sound like a passing assertion :)

What happens in author-land resulting in user error with 3rd party integration should stay there. Mithril already documents its disparities with the spec. There is only so much protection you can reasonably offer!

[dead-claudia]

@barneycarroll And a conforming Promises/A+ implementation would see the m.prop() as a thenable, and would grab the then out of it. If the promise implementation raises a fuss over that, it's a problem with the implementation.

Another breaking change: m.then() doesn't return a memoized value (which it shouldn't). It's another deviation from spec, but it's the expected behavior - you're changing the internal value of the thenable when you call the function.

[barneycarroll]

[dead-claudia]

/cc @lhorie

[StephanHoyer]

typo... and also why not resolve

[dead-claudia]

Don't really know

[dead-claudia]

Merging now. Looking at it again, I don't think that it's a broad enough use case yet that the breaking change would cause problems.

[tinchoz49]

really nice work @isiahmeadows !

[dead-claudia]

@tinchoz49 Thanks!