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 eith
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. becaus
- Original Message -
> On 2012-10-05 9:13 PM, Boris Zbarsky wrote:
> > 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
> >
On 2012-10-05 9:13 PM, Boris Zbarsky wrote:
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. ;)
Nice! Can you please share some
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
On Mon, Oct 1, 2012 at 9:27 AM, 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| me
Nathan Froyd wrote:
IMHO, the current state of affairs for bug 792169 is a little ugly, insofar as
you do:
#include "nsArray.h"
...
nsCOMPtr = nsArray::Create();
...
I can certainly see the advantages of
#include "nsIMutableArray.h"
...
nsCOMPtr array = NewIArray();
[I'm assuming here
- 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
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
On Mon, Oct 1, 2012 at 12:30 PM, Ehsan Akhgari 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
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.
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--especial
12 matches
Mail list logo
