On Mon, Oct 1, 2012 at 12:30 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com>wrote:
> On 2012-10-01 12:27 PM, Nathan Froyd 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?
>>
>
> There might be times where you want the concrete type of the thing that
> your ctor function returns to be opaque, in which case it might make sense
> to go with the NS_NewFoo style of method. But in all other cases I would
> prefer Foo::Create or something like that (or just new Foo, if you don't
> need to do fallible things in the ctor). Basically the more our code looks
> like C++, the better it is for people who have worked on other code bases.
>
Being able to forward declare NS_NewFoo and not need to pull in the headers
necessary for Foo's declaration can be very useful. In general I think we
lean towards including too much, and not forward declaring enough, so I
would like people to keep that part of the tradeoff in mind here.
- Kyle
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
