On 7/31/2013 9:19 PM, Mike Hommey wrote:
On Wed, Jul 31, 2013 at 12:41:12PM -0500, Joshua Cranmer ? wrote:
Thoughts/comments/corrections/questions/concerns/flames/insightful
discussion?
My feeling is that, while these are interesting questions, they are one
step ahead. I think we should step back and start by defining what we
want to achieve.
I think the end goal should be for our code to be more idiomatic, and
less boilerplate-y. Does that mean we should use more STL? maybe, but
I'm not convinced it's the main concern.
Probably most of our boilerplate issues comes from the stilted nature of
XPIDL and XPCOM; deCOMtamination would solve a lot of issues. In same
cases, it may desirable to add more C++-y APIs to things largely
dominated by XPIDL (networking code is the prime example here); other
places already have relatively tolerable C++ APIs ready to use
(mozilla::Preferences, say). XPIDL is presently the only easy way to get
both C++ and JS bindings to code, but the internals of how it works
means that the resulting APIs (for C++ in particular) are far from
natural code, due in part to the need to have predictable ABIs.
I was recently mind-blown by the work the libreoffice people have been
doing to refactor their code, particularly by page 16 in
https://archive.fosdem.org/2013/schedule/event/challenges_libreoffice/attachments/slides/300/export/events/attachments/challenges_libreoffice/slides/300/2013_02_03_re_factoring.pdf
Doing massive refactorings in our code is certainly possible, we just
need to actually commit ourselves to doing those refactorings. I have a
minor goal I'm working towards of removing most uses of NSPR from Gecko...
Now think of all those NS_LITERAL_STRING() and other horrible
boilerplate we have.
... and my next target is s/PRUnichar/char16_t/, the last step of which
basically amounts to killing NS_LITERAL_STRING. :-)
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
