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