It was brought to my attention that it's unclear what I'm looking for in this conversation, so let me try to summarize. I am not convinced that there is something wrong with the way that things currently work (polyfill where the feature is not available everywhere, else use it if appropriate). I'm trying to understand what the shortcomings of the current behavior is. I think it's best if we knew which problems we're trying to solve first.
Cheers, -- Ehsan <http://ehsanakhgari.org/> On Fri, Aug 2, 2013 at 6:47 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com>wrote: > 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
