Re: NS_New$THING vs. new $THING
On 08/10/12 04:14, Boris Zbarsky wrote: On 10/7/12 4:13 PM, Ehsan Akhgari wrote: Nice! Can you please share some info on when you can avoid inheriting from nsISupports and whether we can make the cycle collector aware of such objects? Basically, the rules are as follows: 1) You need to either not need cycle collection (e.g. because you have no wrapper cache and no strong ref members) or need to implement the native CC stuff as Andrew described. 2) Your class must not be the return value of any XPIDL interface, since those go through xpconnect and xpconnect can only deal with nsISupports stuff. The good news is that you can't violate this rule and still compile unless your patch involves reinterpret_cast to nsIWhatever, which will hopefully get you a swift r-. ;) We'll also have to land the patches from https://bugzilla.mozilla.org/show_bug.cgi?id=799465 (I actually have a patch in that bug that removes nsISupports from an existing class). Peter ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: NS_New$THING vs. new $THING
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
Re: NS_New$THING vs. new $THING
On 10/5/12 8:55 PM, Jonas Sicking wrote: With WebIDL you don't even need to use XPCOM interfaces to expose something to javascript! Indeed. As of a few days ago, you don't even need to inherit from nsISupports. ;) -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: NS_New$THING vs. new $THING
Nathan Froyd wrote: IMHO, the current state of affairs for bug 792169 is a little ugly, insofar as you do: #include nsArray.h ... nsCOMPtrnsIMutableArray = nsArray::Create(); ... I can certainly see the advantages of #include nsIMutableArray.h ... nsCOMPtrnsIMutableArray array = NewIArray(); [I'm assuming here that people don't want rv = NS_NewMutableArray(getter_AddRefs(array)); ] -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
NS_New$THING vs. new $THING
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?
-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: NS_New$THING vs. new $THING
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.
Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: NS_New$THING vs. new $THING
On Mon, Oct 1, 2012 at 12:30 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
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
Re: NS_New$THING vs. new $THING
Ehsan Akhgari wrote: 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. That might even apply here, since my understanding was that mutable arrays need to be threadsafe when created off-main-thread and cycle-collected when created on-main-thread, or some such? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: NS_New$THING vs. new $THING
- Original Message - Ehsan Akhgari wrote: 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. That might even apply here, since my understanding was that mutable arrays need to be threadsafe when created off-main-thread and cycle-collected when created on-main-thread, or some such? That's correct. IMHO, the current state of affairs for bug 792169 is a little ugly, insofar as you do: #include nsArray.h ... nsCOMPtrnsIMutableArray = nsArray::Create(); ... -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
