UDP enhancement

[Ali Çehreli]

On 06/30/2013 08:54 PM, JS wrote:

 > On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:

 >> 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.

Agreed. I find implicit storage making code more complex.

 > 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.

Agreed but I was talking about understanding the implementation, not the 
API. When a function returns data.value, it returns the 'value' member 
of a variable 'data'. Where is 'data'? Not a local variable. Not a 
member? A global? Oh! I wonder? Yes, it is an implicit member that is 
created by the compiler.

Note the old proposal that Jonathan has reminded us about does not have 
that problem. It is obvious that we are looking at a property.

 >
 > The old way:
 >
 > @property T x() { }
 > T _x;
 >
 > Is more verbose, and verbose is not always better.

Agreed in general but not in this case.

 > If your class as many
 > variables and some are hidden then it could be difficult to know where
 > the variable is.

That is always possible and requires discipline and coding guidelines. 
The programmers must know to communicate ideas and designs.

 > 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.

I am not against how they make syntax easier. I don't need to prefix 
function names by get_ or set_ and I don't need to use parentheses.

 >> > (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.

How can the compiler put it in *the exact spot* if I am not adding it 
explicitly? Are you suggesting that such functions be inserted between 
other member variables?

struct Foo
{
     int m;
     @property int data() { return data.value; } // read property
     @property int data(int value) { return data.value; } // write property
     double d;
}

What if there is another member between these special functions? 
Compiler error?

 > 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.

I was thinking about structs.

Ali