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.
