On Mon, Oct 1, 2012 at 9:27 AM, Nathan Froyd <froy...@mozilla.com> wrote:
> I recently filed a bug (bug 792169) for adding NS_NewIMutableArray, in
> service of deleting nsISupportsArray. The reviewer asked me to use
> more standard C++ instead of perpetuating the NS_New* idiom and I did
> so, with a static |Create| member function.
>
> However, looking through other code--especially the various bits under
> dom/ that have been added for B2G--I see that the NS_New* style is alive
> and well.
>
> Points for NS_New*:
>
> + Avoid exporting internal datastructures;
> + Possibly more efficient than do_CreateInstance and friends;
> - Usually requires %{C++ blocks in IDL files;
> - Less C++-y.
>
> Points for new and/or static member functions:
>
> + More C++-y;
> + Less function call overhead compared to NS_New* (modulo LTO);
> - Drags in more headers.
>
> ...and there are probably other things that I haven't thought of for
> both of them.
>
> So which style do we want to embrace? Or are there good reasons to
> continue with both?
First off, using do_CreateInstance should generally be very far down
the list of alternatives. You should only really use that if you're
writing a component that you're expecting external developers to be
able to override.
Using NS_New* makes sense if you want to avoid include hell and are
going to be using an XPCOM interface rather than the concrete class to
interact with your object.
However generally speaking, we have been overusing XPCOM interfaces
*way* too much. Ask yourself if you really need an interface or if you
could just as well be using the concrete class. With WebIDL you don't
even need to use XPCOM interfaces to expose something to javascript!
Using concrete classes has enough advantages in code simplicity and
clarity that if you can do it (which is often the case) then it can be
worth adding an extra #include or two. And if you are #including the
header for concrete class rather than xpidl generated interface, then
you've not even added any extra #includes!
/ Jonas
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
