On 11/21/14, 1:17 AM, Yonggang Luo wrote:
I am looking for docs about this
do_CreateInstance returns a new object every time. do_GetService
creates one object and caches it, then keeps returning the cached object.
In practice, for any given class you'd only use one or the other,
depending
I am looking for docs about this
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
W3C recently published the following proposed recommendation (the
stage before W3C's final stage, Recommendation):
http://www.w3.org/TR/IndexedDB/
Indexed Database API
There's a call for review to W3C member companies (of which Mozilla
is one) open until December 18.
If there are comments yo
There is a priority list of best to worst something like this:
1. Types
2. Compile time assertions
3. Unit tests
4. Fatal run time assertions
5. Non-fatal runtime assertions
6. Documentation
This is the order in which you are most likely to quickly find a
problem. Obviously 1 and 2 don't apply to
L. David Baron writes:
>> On 20/11/14 17:56, Boris Zbarsky wrote:
>> > Ah, we can't. We can whitelist the number of assertions in a mochitest
>> > (or a number range if the number is not quite stable), but not the text
>> > of the assertion.
>
> On Thursday 2014-11-20 18:05 +0100, David Rajchenba
I want to use require in
normal XPCOM components.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
> On 20/11/14 17:56, Boris Zbarsky wrote:
> > Ah, we can't. We can whitelist the number of assertions in a mochitest
> > (or a number range if the number is not quite stable), but not the text
> > of the assertion.
On Thursday 2014-11-20 18:05 +0100, David Rajchenbach-Teller wrote:
> I believe th
I believe that we can provide something less fragile than that.
On 20/11/14 17:56, Boris Zbarsky wrote:
> Ah, we can't. We can whitelist the number of assertions in a mochitest
> (or a number range if the number is not quite stable), but not the text
> of the assertion.
>
> -Boris
>
On 11/20/14, 11:51 AM, David Rajchenbach-Teller wrote:
I wasn't aware that we could whitelist an individual NS_ASSERTION. How
do we do that?
Ah, we can't. We can whitelist the number of assertions in a mochitest
(or a number range if the number is not quite stable), but not the text
of the a
I wasn't aware that we could whitelist an individual NS_ASSERTION. How
do we do that?
On 20/11/14 17:24, Boris Zbarsky wrote:
> This sounds lovely.
>
> Note that in C++ for some of our test suites we already have this with
> NS_ASSERTION and for all test suites we have it with MOZ_ASSERT.
> Assum
On 11/20/14, 10:38 AM, David Rajchenbach-Teller wrote:
I have put together an API that could replace runtime warnings with
something much more actionable, and much less noisy. They key aspects
are that:
- when the code is executed as part of the test suite, it causes test
failures;
- individual t
Consider the following scenario:
1. Module A prints warnings when it’s used incorrectly;
2. Module B uses module A correctly;
3. Some future refactoring of module B starts using module A
incorrectly, hence displaying the warnings;
4. Nobody realizes for months, because we have too many warnings;
5
12 matches
Mail list logo
