(Sorry for the late reply, please blame it on Canadian statutory holidays, and my birthday date!)
On Fri, Aug 2, 2013 at 11:09 PM, Brian Smith <br...@briansmith.org> wrote: > On Sat, Aug 3, 2013 at 12:47 AM, 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. > > > 1. It avoids a phase of mass rewrites s/mozilla:Whatever/std::whatever/. > (See below). > 2. It is reasonable to expect that std::whatever works as the C++ standard > says it should. It isn't reasonable to expect mozilla::Whatever to work > exactly like std::whatever. And, often, mozilla::Whatever isn't actually > the same as std::whatever. > As Jeff mentioned, I think it's more important that we expect developers to read and believe the documentation where it exists. The MFBT code is very well documented, and the documentation is usually in sync with the implementation. That is already a huge improvement over the newer std::* stuff. std::auto_ptr is perhaps the biggest example of people not reading documentation about std::* stuff. ;-) But more importantly, as others mentioned, the fact that something lives in the std namespace doesn't mean that it adheres to the C++ standard. So it seems to me like you're assuming that code living in the std namespace is bug free, but that's not true. And when something lives in the std namespace, fixing it is very difficult. But for whatever it's worth, I think that in general, for the std replacement code living in MFBT, it's best for us to try really hard to match the C++ standard where it makes sense. We sometimes go through a crazy amount of pain to do that (see my patch in bug 802806 as an example!). But if something doesn't make sense in the C++ standard or is not fit for our needs, we should do the right thing, depending on the case at hand. > > >> >> 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. > > > You have to rebase all your patches in your patch queue and/or run scripts > on your patches (that, IIRC, don't run on windows because mozilla-build > doesn't have "sed -i"). I'm not complaining about the conversions you've > done, because they are net wins. But, it's still less disruptive to avoid > unnecessary rounds of rewrites when possible, and > s/mozilla::Whatever/std::whatever/ seems unnecessary to me when we could > have just named mozilla::Whatever std::whatever to start with. > I agree that huge refactorings can be a pain. I've been trying to do that in smaller chunks to alleviate some of the pain (see bug 784739 as an example.) If you see people making unjustified huge changes without prior discussion, you should definitely object! But then again I don't find this argument very convincing in this particular case. I hope that this discussion has provided some good reasons why implementing out mozilla::Whatever sometimes makes sense. And later on when we decide to switch to std::whatever, I'd consider such a rewrite a net win because it makes our code easier to approach by people familiar with std::whatever. About the mozilla-build sed issue, that is really really surprising/disappointing -- I'd have expected that we ship GNU sed there? Even bsd sed on Mac supports -i. Please file a bug about this with more details. Cheers, -- Ehsan <http://ehsanakhgari.org/> _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
