On 12/13/11 5:14 PM, Peter Alexander wrote:
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote:
There's a phrase in Romanian that quite applies: "From the lake into
the well".
I believe the English version is "Out of the frying pan, into the
fire" :)
Inconsequential space-filler opinion: I am OK with @property, mainly
because it's a common feature among PLs, it's better than nothing, and
don't know better solutions.
In my opinion, it's not better than nothing.
What it gives you:
1. A bit of syntactic sugar.
2. The ability to refactor member look up easily.
What it costs:
1. Overloads syntax.
a. obj.field can now be an arbitrary function call.
b. May have arbitrary cost (e.g. T[].length)
2. Complicating the language (proof: this discussion)
3. Another thing to learn.
4. Another thing for tools to process.
I don't think the syntax sugar it provides counts for anything really.
The ability to refactor member look ups is nice, but I find that this
rarely occurs in practice and even when it occurs, it's not hard to
replace obj.field with obj.field() or obj.getField().
The costs far outweigh the benefits IMO.
We could have inferred property intention from the code pattern, without
requiring any keyword. That solution (which was discussed and rejected
in this newsgroup) was miles ahead from the drivel of @property we have now.
I noticed there's a tunnel vision phenomenon when it comes to
keyword-based solutions: once a special notation is on the table,
there's no appreciation for anything else. That's what happened with
lazy (another design misfire I'm very unhappy about) and with @property.
I literally feel my heart rate getting up when I think of them.
Andrei
