On Fri, 29 Jan 2010 10:40:23 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Michel Fortin wrote:
On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"
<schvei...@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
