Let’s Bolt: low-level libraries designed to make developing mobile apps easier
blog.parse.com
blog.parse.com
The tl;dr is that you can run into trouble on the iOS platform if you don't enforce a strict 1:1 chain of cause/effects and are very careful about the timing of adding new links to the chain.
This library doesn't appear to do that, and they appear to consider this a feature, and actively push you in that direction. For example, a bullet in the readme is that tasks are "fully composable" and another bullet point discusses adding new tasks to the tree on-demand. These can work on some platforms, but iOS isn't one of them, and so this really reads like someone familiar with JS or .NET trying to add "missing" functionality to iOS without considering why these patterns are not generally used on iOS. Plus, it's trying to achieve API similarity with Android, which is a code smell.
So I would really advise against using this library, at the very least use it a in a superficial way that would be easy to tear out later. If you really want to do this promises thing, I would push you toward Reactive Cocoa, which I am also skeptical about but it's been around much longer, seems to have a much more mature API, and I know at least some smart people who've used it successfully.
Please consider the following as a more frank replacement tl;dr:
"My promises implementation didn't work out for me. Maybe I just didn't go about it the best way, but judge for yourself by reading about my individual experiences, references from 70's papers, a bunch of 'what ifs', no code, no benchmarks, no constructive alternatives, and repeated use of 'we' instead of correctly using 'I'."
Is the above unfair? Maybe somewhat, but if so only as unfair as your representation. I enjoyed your GC article, but any good points to take from "Broken Promises" (or your above comment) are impossible to see through the thickness of pejoratives.
Even if that list of criticisms were accurate, the correct response to an article that has "no code, no benchmarks, no constructive alternatives" is to respond with code, benchmarks, and constructive alternatives. What you do here is essentially say "Because this does not meet some threshold of evidence I can ignore it" instead of what rational people say, "I should collect better evidence but in the meantime let's rely on the evidence that is available".
Finally, you don't really state an articulable position on the actual issue, so the discussion does not really advance. My position is pretty clear: promises work on the platform if and only if there are particular guarantees, and the README of this project explicitly says you don't get those guarantees, ergo this library is trouble. Clearly you object to this position but you do not say, let alone defend, any alternative theory that would have predictive power over whether or not promises will work for a project and for that reason, the comment does not add anything to the discussion.
yeah, you're probably right.
I may be biased, but if you're writing a complex app, you'd do better to get thee to:
At least they're no longer capitalized, as .net naming standards generally follow.
Look at all those square brackets in the Bolt examples.
[[[[[self findAsync:query]
Dalvik patch for Facebook for Android | https://news.ycombinator.com/item?id=5321634
> I can't believe an app requires 8M RAM just for method names!
> They actually did have the stonkingly huge arrogance to monkey patch the OS
> Basically these engineers decided to be really clever, painted themselves
> into a corner, smashed a hole in the wall so as to escape from said corner,
> and then bragged about how great they are.
> Is there any good reason they don't split the functionality to the
> appropriate applications? Then maybe they wouldn't have to hack dalvik to
> run a simple facebook client.https://github.com/mattgreen/elevate
IMO, tasks are the real unit of composition for UI-facing apps: "do this, update the UI in that way, and do this if cancelled". It sure beats writing ad-hoc state handling code every time.
Edit: Bolt's idea of tasks is a lot smaller than Elevate's. Bolt seems to take a promise-esque approach, whereas Elevate combines futures (for I/O) and GCD. It appears Bolt is closer to ReactiveCocoa in spirit.
That said, using the tools of more modern JVM-based languages can tighten up your code in all sorts of ways. An experiment along those lines is here:
https://github.com/rst/positronic_net http://rst.github.io/positronic_docs.html
The latter would give you cleaner code and get rid of any nested blocks.
Overall I love working with ReactiveCocoa. The guys at github run an open source project the way it was meant to be run and are extremely helpful.
One downside is that it makes debugging memory leaks/crashes/retain cycles more difficult but that will be inherent in any block based API. It is still worth using it though.