Accessors, byLine, input ranges

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Jan 29 07:40:23 PST 2010


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.)

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!

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.

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


Andrei



More information about the Digitalmars-d mailing list