On Wednesday 2017-05-10 13:10 +0200, Emilio Cobos Álvarez wrote:
> On Tue, May 09, 2017 at 06:56:03PM -0700, L. David Baron wrote:
> > On Wednesday 2017-05-10 02:43 +0200, Emilio Cobos Álvarez wrote:
> > > The issue I have with per-type conventions is that it doesn't scale very
> > > well, speciall
On Tue, May 09, 2017 at 06:56:03PM -0700, L. David Baron wrote:
> On Wednesday 2017-05-10 02:43 +0200, Emilio Cobos Álvarez wrote:
> > The issue I have with per-type conventions is that it doesn't scale very
> > well, specially when you're writing new code (and more specially if
> > they're not doc
On Wed, May 10, 2017 at 10:27 AM, Karl Tomlinson wrote:
>
> Or is NotNull really too awkward IRL?
>
I wrote NotNull.h, and I've used it in various places. I'm ambivalent about
it. It does make things clear, but it also is a bit annoying to use. The
code tends to end up with WrapNotNull() and get
On Wednesday 2017-05-10 02:43 +0200, Emilio Cobos Álvarez wrote:
> The issue I have with per-type conventions is that it doesn't scale very
> well, specially when you're writing new code (and more specially if
> they're not documented in the style guide).
>
> What should the convention be for `Ser
On Tue, May 09, 2017 at 02:11:41PM -0700, L. David Baron wrote:
> On Tuesday 2017-05-09 11:58 +0200, Emilio Cobos Álvarez wrote:
> > I think references help to encode that a bit more in the type system,
> > and help reasoning about the code without having to look at the
> > implementation of the fu
Nathan Froyd writes:
> I think a broader definition of "POD struct" would be required here:
> RefPtr and similar are technically not POD, but I *think* you'd
> want to require RefPtr* arguments when you expect the smart pointer
> to be assigned into? Not sure.
Yes, please, for similar reasons as
On Tue, May 9, 2017 at 12:05 PM, Boris Zbarsky wrote:
> On 5/9/17 11:41 AM, Nathan Froyd wrote:
>
>> I think I would feel a little
>> better about this rule if we permitted it only for types that deleted
>> assignment operators. Not sure if that's really practical to enforce.
>>
>
> Hmm. I wond
On Tuesday 2017-05-09 11:58 +0200, Emilio Cobos Álvarez wrote:
> I think references help to encode that a bit more in the type system,
> and help reasoning about the code without having to look at the
> implementation of the function you're calling into, or without having to
> rely on the callers t
On 5/9/17 11:41 AM, Nathan Froyd wrote:
I think I would feel a little
better about this rule if we permitted it only for types that deleted
assignment operators. Not sure if that's really practical to enforce.
Hmm. I wonder what happens right now if you try to invoke
nsINode::operator=
On Tue, May 09, 2017 at 06:24:56PM +0300, smaug wrote:
> On 05/09/2017 04:52 PM, smaug wrote:
> > On 05/09/2017 01:55 PM, Mike Hommey wrote:
> > > On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
> > > > On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez
> > > > wrote:
> > > > >
On Tue, May 9, 2017 at 10:39 AM, Boris Zbarsky wrote:
> On 5/9/17 9:17 AM, Nathan Froyd wrote:
>> The argument I have always heard, Gecko-wise and elsewhere [1], is to
>> prefer pointers for modification
>
> This is for primitive-typed out or inout params, right?
I don't remember hearing any dist
On 05/09/2017 04:52 PM, smaug wrote:
On 05/09/2017 01:55 PM, Mike Hommey wrote:
On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote:
I think references help to encode that a bit more in the type system,
and help reasoning
On 5/9/17 9:03 AM, Bobby Holley wrote:
I think passing non-nullable things by reference is good, but I think we
should keep it consistent for a given type.
I should note that we already have this across all types to some extent:
WebIDL bindings pass non-nullable interface types as references,
On 5/9/17 9:17 AM, Nathan Froyd wrote:
On Tue, May 9, 2017 at 5:58 AM, Emilio Cobos Álvarez wrote:
Personally, I don't think that the fact that they're not used as much as
they could/should is a good argument to prevent their usage, but I don't
know what's the general opinion on that.
The arg
On 05/09/2017 01:55 PM, Mike Hommey wrote:
On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote:
I think references help to encode that a bit more in the type system,
and help reasoning about the code without having to look
On Tue, May 9, 2017 at 5:58 AM, Emilio Cobos Álvarez wrote:
> Personally, I don't think that the fact that they're not used as much as
> they could/should is a good argument to prevent their usage, but I don't
> know what's the general opinion on that.
The argument I have always heard, Gecko-wise
As Henri indicates, I think the use of references is consistent with
the style guide.
It's also worth noting that if you are using boxed pointers, then you
almost certainly want to use references to pass them around. I.e.,
foo(const RefPtr& mPtr); // avoids useless ref count
foo(con
I think passing non-nullable things by reference is good, but I think we
should keep it consistent for a given type. So, for example, we shouldn't
have some callsites that take an nsPresContext* and others that take an
nsPresContext& (unless we have a rare case of a nullable presContext arg,
in whi
On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
> On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez
> wrote:
> > I think references help to encode that a bit more in the type system,
> > and help reasoning about the code without having to look at the
> > implementation of the f
On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote:
> I think references help to encode that a bit more in the type system,
> and help reasoning about the code without having to look at the
> implementation of the function you're calling into, or without having to
> rely on the callers to
I like using reference to argument if it's non-nullable.
In Core::Editor module, such arguments are already replaced with
reference in a lot of places.
--
Masayuki Nakano
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.moz
21 matches
Mail list logo