@property needed or not needed?

monarch_dodra monarchdodra at gmail.com
Mon Nov 19 09:58:06 PST 2012


On Monday, 19 November 2012 at 17:42:28 UTC, Dmitry Olshansky 
wrote:
> 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.

Hum... Perhaps you meant:
a.retro
vs
a.retro()
???

Because "retro(a)" works regardless of the property.




More information about the Digitalmars-d mailing list