UDP enhancement

[JS]

On Monday, 1 July 2013 at 16:24:40 UTC, Ali Çehreli wrote:
> 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.

(Well, I'm sure some will find it useful in some cases and I 
don't think such a case could hurt much but I'd probably never 
use it)

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

Well, I personally don't care what symbols or syntax you want to 
use(well, within reason). I used a common syntax because it is 
something people are familiar with. To me it is nitpicking 
because it has nothing to do with the real issue. It's not the 
syntax that is under question but the concept/implementation.

What's important to me is to not have to create a private field 
every time I want to create a property. It seems like a waste of 
time and is verbose for no reason. It doesn't confuse me one bit 
to "hide" the field in the property because essentially that's 
what properties do(to the user of the property)... So it doesn't 
change anything from the outside and only goes to reduce your 
code size.

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

Yes, but any programming language is there to simplify... If we 
had infinite memories and intelligence then direct machine 
language(hex) would be just fine.

IMO by removing excess and essentially useless text in source 
code makes it easier to follow and maintain. Almost all 
programming constructs do this... sometimes it's their sole 
purpose(a macro, function, struct, etc...). (encapsulation of 
data/code is mainly to simplify complexity and not for 
security/safety)

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

I'm not sure we are are talking about the same thing:

> 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


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

}

vs

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


It will almost never matter where the compiler inserts the hidden 
variable for us except when "hacking" the struct(which, as long 
as it's consistent, it shouldn't matter.

to me, the first case is more concise but does EXACTLY the same 
thing. I like things to be concise. I don't wanna see crap that I 
don't need to see. In the 2nd case, val is only required because 
the compiler is not smart enough. We can easily write a 
preprocessor to do the above(in fact, I've done it before).