@property needed or not needed?

Dmitry Olshansky dmitry.olsh at gmail.com
Mon Nov 19 09:42:25 PST 2012


11/19/2012 7:18 PM, monarch_dodra пишет:
> On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:
>> On 11/19/12 4:01 AM, monarch_dodra wrote:
>>> I kind of agree with Jonathan here. @property really shines when you
>>> want to "add" an attribute to a struct.
>>
>> I kind of agree with him, too, but it would be a mistake to not reckon
>> a change in dynamics. UFCS makes all those extra parens just awkward,
>> and people will vote with their code regardless whether some
>> particular viewpoint from some particular angle considers the approach
>> backwards.
>>
>> Andrei
>
> One of the things that we may want to take into account, is that
> -property prevents any existing function from migrating to/from
> property. For example, if we want to make "retro" a property, we can't
> without breaking any and all UFCS usage of retro.
>

The major problem about @property enforcement as it stands is that it 
breaks the duality of things like retro:
a.retro
vs
retro(a)

Both should be allowed as it's a matter of taste that shouldn't be 
enforced. A lot of new code uses a.retro and a lot of older code uses 
retro(a).

If retro is property then only the first one compiles
If retro is a function then only the second one compiles.

Which obviously means @property has to be reconsidered.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list