var { defer, print } = require('meta-promise')
var deferred = defer()
print(deferred.promise.foo.bar.name) // Special print that prints when promise is resolved
print(deferred.promise.baz()) // This does not works yet.
setTimeout(function() { // use require('timer').setTimeout on jetpack
deferred.resolve({ foo: { bar: { name: 'Hello meta-promise!' } }, baz: function() { return 'Hello method' } })
}, 100)
// you will see 'Hello meta-promise!' in 100ms
promise.baz()
Since promise.baz
will have to be a function which can't be an instance of `Promise` (unless Promise === Function). While it's strictly an implementation detail of Q and can be fixed, I do think it's pretty important detail and specification should define it. A promise is an opaque object:I would like to propose to move forward with something different:
- How to send messages to a promise object is beyond the scope of this specification.
- How to detect whether a value is a promise object is beyond the scope of this specification.
- These behaviors are an exercise left to implementers.
- Users of promises must not depend on any particular implementation's behavior.
-- Thanks, Kris
Promises that resolve to arrays can effectively already be proxied by with array methods (and promised-io and everything builts on uses proxied arrays, AKA lazy arrays, extensively). Object-style interaction is what benefits from proxies and even in this case, performance considerations would often preclude the use of proxies.
Ultimately promises need shallow continuations much more than proxies to have better language support.
Defining then() as the basis of promises is elegantly simple, convenient, allows multiple independent implementations, is widely implemented,
and is the right solution even if proxies are someday introduced in EcmaScript.
I've also added an isResolved method to my Q prototype and it seems to
be working well. I'll work on adding an isRejected.
Kris Kowal