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