Comments (7)
Hi Vladimir, thank you for the feedback!
Are you referring the fact we have both canonical concepts of a promise (as an asynchronous provider) and a future (as an asynchronous return object) embodied in one class? Or rather an explicit ability to resolve any promise at anytime from anywhere? Do you suggest to make the pending
constructor return an instance of some other class, like PromiseSource
or Resolver
, and let that one have fulfill
and reject
methods instead of Promise
?
Thanks.
from promises.
@shoumikhin Yes, all of the above.
Promise and its source (aka Future & Promise in terms of some other implementations) should be separate, so that any API (or any protocol or interface for that matter) that returns the Promise object can be sure that user will not be able to interfere with fulfilment and rejection of that promise by API's internal implementation.
Promises should be read-only objects in the sense that they can only be used to monitor pending error/value, not influence their outcome.
Naturally, it implies separating resolving logic into separate class like PromiseSource that will strongly retain corresponding Promise object (but not the other way around).
from promises.
I think that's an interesting idea. I'll convey it to the rest of folks directly involved into Promises development at Google. Feel free to provide a PR or further details or examples on how you'd like to have that implemented. Thanks again for the suggestion!
from promises.
@shoumikhin I don't think there is much to be added in terms of details.
The rationale behind this proposal is the same as with regular mutable/immutable value and value types in general (as in Swift's value types): when you suppling promise as method argument (or returning it from your method) you want to be sure that method's code (or caller of your method) will not be able to interfere with promise's underlying process.
Such interference should be optional and completely separate from Promise class in form of CancelToken #75 (that can also be used for cancellation of async processes, not just unregistration of promise blocks).
from promises.
Hey @virl, I think you bring up a good point about the potential pitfalls of exposing an API that returns a promise that the caller can modify in some way (i.e. by calling fulfill/reject). We are currently looking into potential solutions for addressing this and will hopefully have an update shortly.
Thank you!
from promises.
@virl instead of a separate wrapper class that holds a Promise
, what do you think about a PendingPromise
subclass with fulfill
and reject
methods available?
let promise = PendingPromise<Int>()
// elsewhere
promise.fulfill(42)
The plain Promise
won't simply have those:
let promise = foo.bar().then { ... }
// elsewhere
promise.fulfill(42) // compile error
Thus, the intention becomes explicit, and we can still cast PendingPromise
to a regular "readonly" Promise
and pass it around.
from promises.
Hi @virl, please let us know what you think about the proposal made by @shoumikhin in the comment above. Feel free to reopen this PR if this approach is worth pursuing.
Thank you!
from promises.
Related Issues (20)
- Contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored
- Objective-C Promises crashes in SwiftUI previews HOT 3
- ios 16 strings convertible to NSError HOT 1
- FBLPromises fails to load building macos flutter app HOT 2
- 'NSInvalidArgumentException', reason: '-[FBLPromise HTTPBody]: unrecognized selector sent to instance HOT 1
- Confused when retry a Promise variable
- type(of: value) is NSError.Type HOT 1
- Bitcode Issue on Xcode 13 when disable it. HOT 1
- Question regarding implementation HOT 3
- Ignore a certain Error and terminate Promise HOT 5
- Please release a new version of promises that includes latest changes for Firebase HOT 4
- Builds including PromisesSwift failing on CI
- Build fails for macOS with Xcode 14.3
- Create releases for new versions HOT 1
- The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 12.0 to 17.0.99.
- Privacy manifest for sensitive APIs HOT 6
- Version 2.4.0 not compiling HOT 15
- iOS build issue with 2.4.0 HOT 5
- PrivacyInfo.xcprivacy is not included in the framework output built by Carthage HOT 1
- FBLPromises.xcframework missing mac_catalyst support HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from promises.