On Fri, Aug 02, 2013 at 06:47:08PM -0400, Ehsan Akhgari 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.)
Android and b2g are now using an in-tree STLport copy. We can patch it if necessary, and it will be used everywhere. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform