Accessors, byLine, input ranges

[Steven Schveighoffer]

On Fri, 29 Jan 2010 10:40:23 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Michel Fortin wrote:
>> On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"  
>> <schveiguy at yahoo.com> said:
>>
>>> Hey, it's that dead horse again, let's beat it!
>>>
>>> Andrei and I and several others discussed this ad infinitum.  You  
>>> will  never convince Andrei that his design is wrong :)
>>  Andrei is the one who complained that it's difficult to know whether  
>> 'byLine' is a property in the first place. I'm just explaining why it  
>> is, and what should be done.
>>  I'm starting to think Anrei likes ambiguous semantics.  :-)
>
> I'll tell you what I'd have liked: a landslide of responses to my  
> question revealing my mistaken ways and clarifying without a shade of a  
> doubt that byLine should be a @property. Or not. (I don't even care  
> which.)

It's been mentioned before that tough decisions need to be made in many  
areas of programming.  Deciding what is a property and what is not is no  
different.

Using byLine as the strawman does not disprove the usefulness of  
properties.

>
> The fact we're having a debate about this (and Steve even says it's a  
> clear cut case and there are other more ambiguous!) is worrisome. Take  
> this: I got different answers from _supporters_ of @property!

Again, @property cannot provide an intuitive solution for everything, just  
like ranges cannot solve everything.

> A good convention is one that you apply without wasting time to think of  
> it every single time you use it: naming conventions, braces conventions,  
> even most class vs. struct conventions. The well-defined ones work great  
> because _they save you time_. This @property stuff doesn't save anyone  
> time (the provider is aggravated and the client is aggravated too).  
> Honest, I think it's quite a misfeature. If there's a possibility to fix  
> the ambiguities of the old system, I'd kick @property into oblivion  
> today.

The only one you stated here that is on par with @property is naming  
conventions.  They don't save you time writing code, they save you time  
*reading* code.  The work goes into the writing (how to name this  
properly?  How to make the name intuitive?) and then when reading, it  
comes natural.  Without property you lose part of that concept.  The  
parentheses are an extension of the symbol name, defined by the author,  
nothing more.  What this *means* is up to you.  In fact, properties *are*  
an extension of naming conventions.

> We need digitalmars.D.is_it_a_property_or_not. Whenever in doubt, people  
> can ask a question there.

OK:

digitalmars.d.should_this_be_a_class_or_struct.
digitalmars.d.should_this_symbol_be_capitalized.
digitalmars.d.should_this_use_a_function_pointer_or_delegate.
digitalmars.d.should_this_be_const_or_immutable.

Can we ever get any work done without these?

-Steve