On 31 Aug 2015 at 12:10, Gavin Lambert wrote:
I'd live comfortably with what you just proposed. In fact, it was my second preference API design after the one I chose. I felt originally that making the end user write depends() all over the place would be irritating, but maybe it's better to force the end user to always be explicit about what operations relate to which others.
I think this might end up being a little cleaner, despite being more verbose at first glance. In theory then all the functions that accept preconditions would just be very thin wrappers that simply "return precondition.then(actual operation)" (or similar; I'm not sure if you need an extra layer to cope with "depends" returning an unready future).
If the "actual operation" API were also public then this might also satisfy the folks in the other thread that want to avoid having precondition parameters at all.
Bear in mind that once coroutines or async/await are better established in the language, it's likely that there would be no need for precondition parameters as it would be simpler to attach continuations at the top level.
I think I can make the above work well. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/