Fixing const arrays

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Dec 13 15:08:43 PST 2011


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


More information about the Digitalmars-d mailing list