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"
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).
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.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
