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

Reply via email to