llvm dev - Mar 2014 - [LLVMdev] [cfe-dev] C++11 reverse iterators (was C++11 is here)

On Mar 3, 2014, at 12:04 AM, Chandler Carruth <chandlerc at google.com>
wrote:
>> I was actually going to check in this, but I can post it for review if
folks are worried.
>> 
>> My plan was to provide an implementation of
std::iterator_range<T> and then provide 'F.arguments()' which
returns it.
> 
> Nice.  What's the logic behind .arguments() vs .getArguments()?  I
don't have a strong opinion either way, but there should be rationale.
> 
> In the best case 'get' doesn't really add any meaning, and in
the worst case it is actively misleading
It's getting the range though, just like Function::getArgumentList() returns
the argument list.
> For example, you might iterate over operands, and assign through the
iterator to mutate them.
> 
> Really, these operate as range-views over some sequence. It seems
particularly easy to teach foo_begin(), foo_end() -> foos() as well.
That's a very objective-c thing to do :-), they use the pattern foo() and
setFoo() for the getter and setter, respectively (and the naming is baked into
the property model).  I don't feel strongly against it, but we pretty
consistently use the Java style 'get' prefix everywhere else.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140303/2f17c2b9/attachment.html>

On 3 Mar 2014, at 17:48, Chris Lattner <sabre at nondot.org> wrote:
> That's a very objective-c thing to do :-), they use the pattern foo()
and setFoo() for the getter and setter, respectively (and the naming is baked
into the property model).  I don't feel strongly against it, but we pretty
consistently use the Java style 'get' prefix everywhere else.
The Objective-C (technically, OpenStep) convention is to use getFoo when you
provide a buffer into which the thing will be put, which isn't the case
here.  My reason for proposing foo() instead of getFoo() is that getFoo(), to
me, implies that now you have a foo that you can hang on to for a bit, whereas
the object returning the reverse iterators is intrinsically a transient thing. 
You don't want people doing:

auto args = foo.arguments();

And then later doing:

for (auto arg : args)
  ...

While this may be a valid thing to do, determining whether it actually is
requires some thought.  I would be more inclined to expect it to unconditionally
work if the method were called getArguments() than if it is called arguments(),
but that may be personal bias.

The only places where the C++ standard library uses get (from my memory, may be
completely wrong) are when there is some notion of ownership transfer.  When
referring to internal properties of an object, the name is undecorated (see the
begin() and end(), not get_begin(), get_end(), that are the original cause of
this discussion...)

David

On Mon, Mar 3, 2014 at 9:48 AM, Chris Lattner <sabre at nondot.org> wrote:
> In the best case 'get' doesn't really add any meaning, and in
the worst
> case it is actively misleading
>
>
> It's getting the range though, just like Function::getArgumentList()
> returns the argument list.
>
I really disagree (and I disagree with getArgumentList for the same reason).

getFoo should return something with value semantics (even if its a const
reference to delay the copy). setFoo should directly mutate something.

What we're really doing is making the equivalent of a "member-like
accessor" method.

>
> For example, you might iterate over operands, and assign through the
> iterator to mutate them.
>
> Really, these operate as range-views over some sequence. It seems
> particularly easy to teach foo_begin(), foo_end() -> foos() as well.
>
>
> That's a very objective-c thing to do :-), they use the pattern foo()
and
> setFoo() for the getter and setter, respectively (and the naming is baked
> into the property model).  I don't feel strongly against it, but we
pretty
> consistently use the Java style 'get' prefix everywhere else.
>
If we have a setFoo, then I'm with you we should have a value-semantic
getFoo. But we have just plain "op_begin" and "op_end" and I
think that
makes sense to extend to a range adaptor "operands".
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140303/dfe89509/attachment.html>

On Mar 3, 2014, at 10:29 AM, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> On Mon, Mar 3, 2014 at 9:48 AM, Chris Lattner <sabre at nondot.org>
wrote:
>> In the best case 'get' doesn't really add any meaning, and
in the worst case it is actively misleading
> 
> It's getting the range though, just like Function::getArgumentList()
returns the argument list.
> 
> I really disagree (and I disagree with getArgumentList for the same
reason).
> 
> getFoo should return something with value semantics (even if its a const
reference to delay the copy). setFoo should directly mutate something.
> 
> What we're really doing is making the equivalent of a "member-like
accessor" method.
Ok, can this be generalized into guidance we can put in the coding standards?

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140303/2e0bb6ab/attachment.html>