DIP26: properties defined

Rob T alanb at ucora.com
Sat Feb 9 00:41:23 PST 2013


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



More information about the Digitalmars-d mailing list