Fixing const arrays

Timon Gehr timon.gehr at gmx.ch
Tue Dec 13 15:11:19 PST 2011


On 12/14/2011 12:14 AM, 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)

??? T[].length is a field access, not a property function. It takes a 
small constant amount of time.

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



More information about the Digitalmars-d mailing list