On 2013-08-02 5:21 PM, Brian Smith wrote:
3. How should we handle bridge support for standardized features not yet
universally-implemented?
Generally, I would much rather we implement std::whatever ourselves than
implement mozilla::Whatever, all other things being equal.
Yes, but it's still not clear to me why you prefer this.
This saves us
from the massive rewrites later to s/mozilla::Whatever/std::whatever/;
while such rewrites are generally a net win, they are still disruptive
enough to warrant trying to avoid them when possible.
Disruptive in what sense? I recently did two of these kinds of
conversions and nobody complained.
In the case where it
is just STLPort being behind, we should just add the thing to STLPort (and
try to upstream it). in the case where the lack of support for a useful
standard library feature is more widespread, we should still implement
std::whatever if the language support we have enables us to do so. I am not
sure where such implementations should live.
Yes, upstreaming fixes is clearly ideal, but sometimes pragmatism wins.
For example, I personally wouldn't have the first clue what I need to
do in order to modify STLport (how to make b2g/Android builds use my
modified library, how to upstream the fix, what to do when we pick up
the changes, how long that would take, what to do if my changes are not
accepted upstream, etc.)
4. When should we prefer our own implementations to standard library
implementations?
It is a judgement call. The default should be to use standard library
functions, but we shouldn't be shy about using our own stuff if it is
clearly better. On the other side, we shouldn't be shy about replacing uses
of same-thing-but-different Mozilla-specific libraries with uses of the
standard libraries, all things being equal.
If you agree that it's a judgement call, then prescribing what the
"default" should be is, well, also a judgement call!
6. Where support for an API we wish to use is not universal, what is the
preferred way to mock that support?
[Note: similar questions also apply to NSPR and NSS with respect to newer
C99 and C11 functionality.]
There is no tolerance for mass changes like s/PRInt32/int32_t/ in NSPR or
NSS, AFAICT.
We mostly treat those libraries as read-only anyway, for the better or
worse.
C99 and C11 are basically off the table too, because Microsoft
refuses to support them in MSVC.
Yes, focusing on improving C code like this is a lost cause.
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
