On Saturday, 9 February 2013 at 07:45:05 UTC, FG wrote:
On 2013-02-09 08:19, Dmitry Olshansky wrote:
NoUFCS for properties
Properties protect the access to a field of an entity
(class/struct/module),
so they actually have to be defined within the entity they
belong to, just as
a field would.
Rubbish.
std.array:
@property auto front(T)(T[] arr)
{
return arr[0];
}
Yeah, banning UFCS for properties is too farfetched.
This attempt to define a standard definition shows that the idea
of a property means different things depending on the person you
ask and what they are trying to accomplish.
The current @property implementation is no good for the
encapsulation definition, however it is great for what the
compiler currently implements, which are regular functions with
(soon to be) enforced getter and setter syntax.
If we also want encapsulating properties that emulate variables
as much as possible, that's a different type of property from the
type that does not encapsulate and try to fully emulate a
variable. @property simply cannot do both. What's missing is the
ability to wrap true private internals into a property namespace.
This idea was presented a few times already, as it appears to be
a reasonable solution.
I really don't see why we cannot implement the non-encapsulated
@property implementation, which is essentially what we already
have except with enforced getter/setter syntax and weak variable
emulation (its just a regular function), and later after the dust
settles we implement a real property with true powers of
encapsulation and more precise variable emulation, although not
to replace @property because it does a good job for what it is
design to do.
--rt
