UDP enhancement

Piotr Szturmaj bncrbme at jadamspam.pl
Sun Jun 30 19:08:20 PDT 2013


W dniu 01.07.2013 03:35, Jonathan M Davis pisze:
> On Monday, July 01, 2013 03:22:15 JS wrote:
>> struct Foo
>> {
>>       @property int data() { return m_data; } // read property
>>       @property int data(int value) { return m_data = value; } //
>> write property
>>       private: int m_data;
>> }
>>
>> It would be nice if properties had an internal variable to use
>> instead of having to declare it explicitly:
>>
>>
>> struct Foo
>> {
>>       @property int data() { return data.value; } // read property
>>       @property int data(int value) { return data.value; } // write
>> property
>> }
>>
>> This reduces code complexity. If a property does not use the
>> internal variable(which I signify by .value) then it does not add
>> any storage. This allows one to easily wrap fields into
>> properties without having to create private fields for each
>> property unless needed.
>
> I believe that the way that this sort of enhancement has typically been
> suggested is to do something like
>
> public @property int value;
>
> which would be lowered to something like
>
> public @property int value() @safe const pure nothrow { return _value; }
> public @property int value(int v) @safe pure nothrow { return _value = v; }
> private int _value;

This is nice, and this pattern promotes overriding of properties.

> And I think that that's clearer than your suggestion (it's definitely shorter).
> It also doesn't require the compiler to infer anything about whether you meant
> to have it create a variable or not. It simply tells the compiler what to do
> in a more concise manner.

Yes, it's clearer and more importantly it doesn't hide aggregate fields 
inside methods. Data layout of an aggregate should be clear IMHO.


More information about the Digitalmars-d mailing list