UDP enhancement
JS
js.mdnq at gmail.com
Sun Jun 30 20:54:03 PDT 2013
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.
More information about the Digitalmars-d
mailing list