UDP enhancement

[JS]

On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:
> On 06/30/2013 06:43 PM, JS wrote:
>
> >> 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.
>
> I have the complete opposite view: Seeing what m_data 
> explicitly in the code would be simpler than reading code to 
> see that data.value would mean implicit storage.
>

huh? There is absolutely no semantic difference between the two. 
The proposed case is easier because the field can't be hidden 
away somewhere making it hard to find.

@property T x() { }

represents a function and possibly a variable of type T. You know 
that by looking at the property. It is not a hard leap to 
understand.

The old way:

@property T x() { }
T _x;

Is more verbose, and verbose is not always better. If your class 
as many variables and some are hidden then it could be difficult 
to know where the variable is.

If the field is not of the same type then either the original 
method can be used or possibly an extension:

@property T:W x() { return x.value.t; }

represents the same as

@property T x() { return _x.t; }
W _x;

There is absolutely no difference in semantics... just syntax. 
One is more verbose. It shouldn't be difficult to see that.

It's no different than writing separate setters and getters... no 
difference... just they are more verbose. If you are against my 
suggestion you should be against properties in general because 
they are a simplification of such.

> > (if propertyname.value is used then
> > there needs to be an internal variable, else not),
>
> Where would the compiler make room for that variable in 
> relation to the other members? With programming languages, 
> explicit is almost always better than implicit.
>
> Ali

huh? The exact same place it does so if the programmer explicitly 
adds it. It's location in the class my not be the same but that 
is, in general, irrelevant unless you are messing with the bits 
of the class.