byKey and byValue: properties or methods?

[Nick Sabalausky]

"Peter Alexander" <peter.alexander.au at gmail.com> wrote in message 
news:jf4ull$n6b$1 at digitalmars.com...
> On 17/01/12 10:11 PM, Jonathan M Davis wrote:
>> You would need to come up with some really solid arguments why it should 
>> be
>> thrown out (and what we should do instead) and get both Walter and Andrei 
>> (if
>> not the community at large) to agree that they not only prefer your 
>> proposal
>> but that it's worth the issues that the changes are going to cause at 
>> this
>> stage.
>
> There's a few good reasons to throw it out:
>
> 1. Avoids pointless discussions like this one. These discussions add 
> nothing, it's just mindless bike shedding.
>

Andrei's the only one that ever starts any of this "Is this a property or 
func?!?" nonsense, because he's been against the distinction from the start. 
We finally got him to give in due to the delegate ambiguity, and he's been 
bitching about it at every opportinity since.

> 2. The -property flag *creates* a new kind of error, but doesn't actually 
> help find real problems with your code. Without properties, member 
> function access would always be a.b(), and this artificial error could be 
> avoided.
>

Bullshit. Without properties, member function access *ANY* many value 
accesses are "a.b()". Is this member value a plain-old-var or a function? 
Who knows! It's a leeked out implementation detail, hooray!

> 3. Properties introduce another thing to remember, with no value ("was it 
> byKeys, or byKeys()?"). Without properties, it would be byKeys(). No need 
> to remember.
>

Of *course* there's a need to remember useless shit: There's a need to 
remember that it's implemented as a function and not just simply as a member 
variable. In this *particular* case it may be a little easier since we know 
it returns range, but what about "aa.keys"? What about every other property 
out there?

> 4. Properties obfuscate code. Is (a.b = c) a variable assignment or 
> arbitrary function call? Who knows! Is a.b an actual variable?

Who the hell cares? The whole damn *point* is that you don't have to give a 
shit about the member's implementation on *every* fucking member access. If 
you want transparency, use assembler.

> Can I write &a.b to get its address, or is it a function masquerading as a 
> variable?
>

That's only an issue when you actually want to take the address of something 
(and there are ways to improve that situation anyway). But forcing every 
property to be used as if it were a function instead of data access forces 
the user to figure out how it's implemented *EVERY* time it's accessed.

> 5. One less language feature to implement, learn, document, debug, and 
> discuss.
>

So we're taking the Java/JavaScript/Brainfuck route of "minimal language == 
good langauge" now?

> Is it practical or realistic to throw it out at this stage?

I wouldn't think so even if I wanted them gone.

> I don't know. But there are reasons to.

No there aren't. The only reason to throw it out is that Andrei keeps 
whining and moaning about it just because it's something he can't/won't 
grok. But being that he's Andrei, that just might end up being enough of a 
reason, which is why I'm so insistent about the matter.