Hi Joshua!
Thanks for taking the time to read and reply!
Please read my answers inline...
On May 8, 2013, at 6:17 AM, Joshua Cranmer 🐧 <[email protected]> wrote:
> On 5/7/2013 8:49 AM, Mike de Boer wrote:
>> I've told some of you before that I'm not a big fan of Promise libraries (if
>> not, please read the 10 reasons to NOT use a Promise library:
>> https://gist.github.com/mikedeboer/5305020).
>
> For what it's worth, I am very unpersuaded by your argumentation. Rebutting
> your reasons:
> 1. Promises aren't meant to solve the async problem. In effect, they take
> code which would be written in a continuation passing style and rewrite that
> into a more natural serial chaining.
> 2. I'll grant you this, but this is a casualty of CPS code in general.
> 3. I don't understand your complaint here, and this may be because I'm trying
> to compare promises with similar use cases and you are not.
> 4. This is no more a problem than CPS code in general has. Actually, promises
> helps this by being able to propagate an exception to the last rejection
> handler. In effect, it brings back the notion that a careful API consumer can
> fix the problem of a careless API author.
> 5. This is true for general code on the web. This is not true for Mozilla
> code, where we have a single promises implementation.
> 6. Ditto. This also strikes me as "I didn't write this, therefore it sucks"
> syndrome.
> 7. It has been my experience that the environment of testing is often such a
> diverse field that everything breaks down into ad-hoc algorithms. Look
> through all of the xpcshell tests in comm-central to see what I mean.
> 8. Again, this strikes me as "I didn't write this, therefore it sucks." See
> also below.
> 9. All API tends to be inherently viral. It's hard to mix sync and async
> code, for example. At some level, most code is basically a glorified way to
> move data from one API to another.
> 10. Paraphrasing, this is "Promises are bad because they force you to write
> the promises model" (with an implicit "and that model is bad"). It's hard not
> to take this as "Promises are bad because I hate promises"
>
I hope I clarified my position well enough in my reply to Mark Hammond earlier.
I was actually hoping to not go into this discussion, because my point is not
at all about trying to get rid of Promises or something else that silly. Paolo
Amadini is working on a constant stack space Promise implementation, which aid
us much in both adoption and debuggability (see bug 810490).
I think any further discussion should be focussed to commenting on the Gist.
My main point is that Promise and continuation passing style (CPS) are not
mutually exclusive and have their own use cases. I will make an effort to make
a conscious choice which of the two to use in my projects now and in the
future. The use of CPS in AsyncTest.jsm is an example where I made such a
decision consciously and not due to something silly and emotional like "I hate
Promises" or "it sucks". For testing synchronous code you can forget about CPS
altogether and omit the callbacks.
> It's also interesting to note that your points 5, 6, and 8 are slippery slope
> arguments. Change a few words:
>
> 1. C++ implementations differ a LOT from each other, most often in the
> area of semantics. This makes it so that you may know one
> implementation, but can not use another.
> 2. The most-often used C++ implementations are not easy to contribute
> to. It isn't bug free (no software is). If you encounter one, the
> code is complex enough, so you'd have to wait until a more active or
> seasoned developer may be able to fix it.
> 3. in general - and more towards an opinion: you shouldn't use a helper
> library that you wouldn't be able to write yourself upon first
> glance. It might help you at first, but not in the long run.
>
> Therefore, we should write all of our code in native machine code because we
> can't rely on C++ implementations, right? (There is a very long history of
> having to work around buggy compilers in our code, and probably many more
> problems have been uncovered in trying to build portable C/C++ code than you
> have seen between all promise libraries).
>
Hmm, I think you're trying to compare apples with oranges here; please
understand that I'm trying to make people aware of potential pitfalls of using
Promise polyfills and not the concept, design and theory behind the struct - if
they weren't already. If that were my goal, then I might've just shot myself in
the foot right away. I've been following the es-discuss threads that subject
Promise standardization and the WebIDL DOM Future work with great interest and
I believe we're well moving forward here. Work being done by the Async
Responsive workgroup led by David Rajchenbach Teller is also important
regarding this.
>
>> You can pass an Array of test suites or just one Object
>> Suites can have names
>> Tests can be described freely
>> It mixes fine with ANY assertion style (Mochi or XPCShell)
>> Prefix a test with ! to exclude it from the suite. This is something that is
>> practically useful when doing TDD.
>> Prefix a test with > to only run that test and ignore the others. It is
>> meant to signal out a test case and run only that specific one. This is
>> something that is practically useful when doing TDD.
>> If the test is sync, you can forget about the next function (callback)
>> completely - the library takes care of it; you can even mix async and
>> non-async tests
>
> Forgive me for saying this, but it sounds like using this test suite is a lot
> more painful for not using it. The tests that I need to write tend to come in
> two categories. Either they're a series of functions which run for an
> asynchronous amount of time, which yields tests like
> <http://mxr.mozilla.org/comm-central/source/mailnews/news/test/unit/test_internalUris.js>,
> or they are running essentially the same code on a large body of test
> inputs, like
> <http://mxr.mozilla.org/comm-central/source/mailnews/mime/test/unit/test_parser.js>
> (large is relative--the rest of those tests are sitting in patches awaiting
> review). The former uses a common test framework for comm-central
> (<http://mxr.mozilla.org/comm-central/source/mailnews/test/resources/asyncTestUtils.js>),
> while the latter is an example of one my many ad-hoc test frameworks.
>
AsyncTest.jsm as it stands now is not a framework, just a library. It favors
convention over configuration and flexibility over constraint or boxing-in a
specific technology. It doesn't tie in to Mochi or XPCShell or any other test
runner, just augments them.
A common library to do assertions is another thing that's high on my 'OMG
WANT!' list, but I don't dare burning my fingers on such a project alone.
In the examples you provided I fail to see how they wouldn't work nicely with
AsyncTest.jsm… would it help our mutual understanding if I ported them and
check it out together?
> --
> Joshua Cranmer
> Thunderbird and DXR developer
> Source code archæologist
>
> _______________________________________________
> dev-platform mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-platform
Again, thanks for your time!
Mike.
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
