Accessors, byLine, input ranges

[Bill Baxter]

On Fri, Jan 29, 2010 at 10:41 AM, Michel Fortin
<michel.fortin at michelf.com> wrote:
> On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> Steven Schveighoffer wrote:
>>>
>>> On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>
>>>> Consider:
>>>>
>>>> struct Stack(T) {
>>>>     T pop();
>>>>     ...
>>>> }
>>>>
>>>> By your definition, pop() should be a property. It doesn't quite strike
>>>> me as an intuitive decision.
>>>
>>> is pop's main purpose to fetch a value or to modify the stack?  I'd say
>>> the purpose is split equally, so it's not a function whose main purpose is
>>> to fetch a value.
>>
>> So now we're down to proportions, nuance, and where "main" goes. You made
>> my point. I win.
>
> You win because Steven's definition is not good enough. I said before that
> we should have a authoritative definition. If we really can't define how a
> property should be defined after some reflection, then you really win.
>
> My definition is that a property gives access to an aspect of an object and
> doesn't modify it (the getter is essentially logical-const). In this case,
> 'pop' doesn't give you access to something in the stack, it removes an
> element (that's an action) and give you the element. It's pretty clear that
> 'pop' is used as a verb here, that should be enough to decide it's a
> function.

One more example to consider:  RNG.randomInt()  or RNG.randomInt

I think Steven is right that you can always find corner cases, but
that the existence of corner cases is pretty irrelevant.

--bb