11/19/2012 9:58 PM, monarch_dodra пишет:
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()
This one too.
Because "retro(a)" works regardless of the property.
Hm.. being a while since I tried to use -property switch. I thought it
was also disallowed. Not so bad then I guess.
Looking forward to DIP21.
--
Dmitry Olshansky
