Thread overview | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 20, 2014 Really nooB question - @property | ||||
---|---|---|---|---|
| ||||
There are a lot of discussions in the forums about how @property should or could be implemented. But I can't seem to find anything that explains why or when I should use @property with the current compiler. Can anyone explain why and when I should use the @property tag? Thx. Eric |
July 20, 2014 Re: Really nooB question - @property | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eric | On Sunday, 20 July 2014 at 16:35:52 UTC, Eric wrote: > > There are a lot of discussions in the forums about how @property > should or could be implemented. But I can't seem to find anything > that explains why or when I should use @property with the current > compiler. Can anyone explain why and when I should use the @property tag? > > Thx. > Eric I wondered the same: http://forum.dlang.org/thread/uskutitmqgdfjeusrtfv@forum.dlang.org |
July 20, 2014 Re: Really nooB question - @property | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eric | On Sunday, 20 July 2014 at 16:35:52 UTC, Eric wrote:
>
> There are a lot of discussions in the forums about how @property
> should or could be implemented. But I can't seem to find anything
> that explains why or when I should use @property with the current
> compiler. Can anyone explain why and when I should use the @property tag?
>
> Thx.
> Eric
Use @property when you want a pseudo-variable or something that might be conceptually considered a "property" of the object, i.e. to do this:
auto blah = thing.someProperty;
thing.someProperty = blahblah;
or
struct myArray(T)
{
T[] arr;
@property size_t memSize() { return arr.length * T.sizeof; }
}
Other than that, don't use it. Ordinary functions can be called without parenthesis anyway.
Using those ideas you shouldn't run in to any surprises.
|
July 20, 2014 Re: Really nooB question - @property | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | On Sunday, 20 July 2014 at 17:59:07 UTC, John Colvin wrote:
> On Sunday, 20 July 2014 at 16:35:52 UTC, Eric wrote:
>>
>> There are a lot of discussions in the forums about how @property
>> should or could be implemented. But I can't seem to find anything
>> that explains why or when I should use @property with the current
>> compiler. Can anyone explain why and when I should use the @property tag?
>>
>> Thx.
>> Eric
>
> Use @property when you want a pseudo-variable or something that might be conceptually considered a "property" of the object, i.e. to do this:
>
> auto blah = thing.someProperty;
> thing.someProperty = blahblah;
>
> or
>
> struct myArray(T)
> {
> T[] arr;
> @property size_t memSize() { return arr.length * T.sizeof; }
> }
>
> Other than that, don't use it. Ordinary functions can be called without parenthesis anyway.
>
>
> Using those ideas you shouldn't run in to any surprises.
Oh, but don't expect the compiler to enforce this and please don't use the -property flag, it will only cause you pain.
|
July 20, 2014 Re: Really nooB question - @property | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin |
> Use @property when you want a pseudo-variable or something that might be conceptually considered a "property" of the object, i.e. to do this:
>
> auto blah = thing.someProperty;
> thing.someProperty = blahblah;
>
This is basically what I suspected. But why
write:
@property int getValue() { return(value); }
When you could just have a public field:
int value;
That lets you set and get the value without the parens anyways?
thanks,
Eric
|
July 20, 2014 Re: Really nooB question - @property | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eric | On 07/20/2014 11:14 AM, Eric wrote: > >> Use @property when you want a pseudo-variable or something that might >> be conceptually considered a "property" of the object, i.e. to do this: >> >> auto blah = thing.someProperty; >> thing.someProperty = blahblah; > > This is basically what I suspected. But why > write: > > @property int getValue() { return(value); } > > When you could just have a public field: > > int value; > > That lets you set and get the value without the parens anyways? Freely setting a member makes sense only in limited cases where that member does not take any part in any invariant of the object. For example, if a Rectangle class has .length, .width, and .area, it would be an error to set either of them. Additionally, properties enable one to make it look like a type has such a member: struct Rectangle { // ... @property int area() { return length * width; } } Ali |
July 21, 2014 Re: Really nooB question - @property | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eric | On 7/21/2014 3:14 AM, Eric wrote: > >> Use @property when you want a pseudo-variable or something that might >> be conceptually considered a "property" of the object, i.e. to do this: >> >> auto blah = thing.someProperty; >> thing.someProperty = blahblah; >> > > This is basically what I suspected. But why > write: > > @property int getValue() { return(value); } > > When you could just have a public field: > > int value; > > That lets you set and get the value without the parens anyways? > > thanks, > > Eric In addition to what others have pointed out, it's useful for read-only values. You don't always want to allow clients to be able to set an objects members. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
July 21, 2014 Re: Really nooB question - @property | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eric | On Sunday, 20 July 2014 at 18:14:29 UTC, Eric wrote:
>
>> Use @property when you want a pseudo-variable or something that might be conceptually considered a "property" of the object, i.e. to do this:
>>
>> auto blah = thing.someProperty;
>> thing.someProperty = blahblah;
>>
>
> This is basically what I suspected. But why
> write:
>
> @property int getValue() { return(value); }
>
> When you could just have a public field:
>
> int value;
>
> That lets you set and get the value without the parens anyways?
>
> thanks,
>
> Eric
It allows you to add extra logic on read/write, without breaking any user code.
|
July 21, 2014 Re: Really nooB question - @property | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eric | On Sunday, 20 July 2014 at 16:35:52 UTC, Eric wrote:
> There are a lot of discussions in the forums about how @property
> should or could be implemented. But I can't seem to find anything
> that explains why or when I should use @property with the current
> compiler. Can anyone explain why and when I should use the @property tag?
Consider the following struct:
struct Vector4 {
@property float x() { return vec[0]; }
.....
.....
@property void x(float _x) { vec[0] = _x }
.....
.....
private:
float[4] vec;
}
Here I like to use static array for storing components of vector because I want to use special operations on arrays while taking advantage of auto-vectorization if possible. In this case, it is very convenient to use properties.
|
July 21, 2014 Re: Really nooB question - @property | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eric | On Sunday, 20 July 2014 at 18:14:29 UTC, Eric wrote:
>
>> Use @property when you want a pseudo-variable or something that might be conceptually considered a "property" of the object, i.e. to do this:
>>
>> auto blah = thing.someProperty;
>> thing.someProperty = blahblah;
>>
>
> This is basically what I suspected. But why
> write:
>
> @property int getValue() { return(value); }
You should use nouns to name properties and verbs to name methods. D has optional parentheses, so you can write x=getValue;
So @property is generally not needed except for the case when the method returns a delegate, which in its turn can be implicitly called, so there's an ambiguity, which @property was meant to solve (but AFAIK in the end it didn't). It also serves as a documentation, that the method should be viewed as a property. Initially optional parentheses were meant as an easy implementation of properties, and @property wasn't meant to exist until the ambiguity with the delegate was understood.
|
Copyright © 1999-2021 by the D Language Foundation