www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Are properties actually all that good?

reply "Land" <Land email.com> writes:
I was just thinking about properties and to be honest, I don't
like them all that much. There's no way to tell if it's a
read-only or write-only property (right?), but getValue and
setValue are pretty self-explanatory.

Also, someone was angry about .keys making a copy. I agree with
that person and think that instead of a property, there should be
a method called copyKeys or getKeysCopy to make it obvious.

Or does anyone have different view on the matter? I'd be happy to
hear it.
Jul 22 2013
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 22 July 2013 at 15:07:29 UTC, Land wrote:

 I was just thinking about properties and to be honest, I don't
 like them all that much. There's no way to tell if it's a
 read-only or write-only property (right?), but getValue and
 setValue are pretty self-explanatory.

 Also, someone was angry about .keys making a copy. I agree with
 that person and think that instead of a property, there should 
 be
 a method called copyKeys or getKeysCopy to make it obvious.

 Or does anyone have different view on the matter? I'd be happy 
 to
 hear it.


You are opening a big can of worms on this subject. There is a 
500 message debate on this. The basic idea of "properties" is 
(was) that it was supposed to make an abstraction of what is 
actually a data member, or what needs to be calculated (via a 
function).

For example, for a range, you may inquire "empty" or "length", 
without having to worry about things like "was this one 
getLength? or simply length"? Do you *care*? *Should* you care?

So the idea was to make it easier for the end user to not have to 
worry about such implementation details: If it "feels" like a 
member variable, you should be able to *handle* it like a member 
variable.

This was in theory. In practice, the lack of support in the core 
language, or the fact that it was mixed with the notion of 
"optional parens" have corrupted what it was originally designed 
for.

Honestly, I don't even know *what*  property does today, nor what 
it *should* do.

I think the only thing it still does is get the address of the 
returned object when you write "&foo".
Jul 22 2013
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/22/2013 08:07 AM, Land wrote:


 I was just thinking about properties and to be honest, I don't
 like them all that much. There's no way to tell if it's a
 read-only or write-only property (right?),


Documentation should make it clear. Otherwise, it should be possible to 
detect whether a property is read-only, etc. a la templates in std.traits.


 but getValue and setValue are pretty self-explanatory.


Agreed, but as I said in that earlier thread, I find it repetitive and 
unnecessary when it is obvious:

     cpu.temperature;

The following is also slightly wrong, in the sense that it is not 'cpu' 
that will get the temperature:

     cpu.getTemperature();

Temperature is a property of 'cpu'; there shouldn't be a verb associated 
with it. The whole issue is not that important anyway. However 
imperfect, everybody understands what get/set methods are. (Judging from 
the word "method", they must be common in languages that have "methods". ;))


 Also, someone was angry about .keys making a copy. I agree with
 that person and think that instead of a property, there should be
 a method called copyKeys or getKeysCopy to make it obvious.


Agreed. It is simply historical.


 Or does anyone have different view on the matter? I'd be happy to
 hear it.


Ali
Jul 22 2013
parent reply "Land" <Land email.com> writes:
Thank you for the replies. So, what's the bottom line? Should I 
use accessor methods or should I use properties? (I've read quite 
a bit of the mentioned 500-post topic, by the way, but I'm still 
not clear on what's the most logical step here)
Jul 22 2013
next sibling parent "develop32" <develop32 gmail.com> writes:
On Monday, 22 July 2013 at 16:42:57 UTC, Land wrote:

 Thank you for the replies. So, what's the bottom line? Should I 
 use accessor methods or should I use properties? (I've read 
 quite a bit of the mentioned 500-post topic, by the way, but 
 I'm still not clear on what's the most logical step here)


In my case I use both. If function is bigger than certain 
threshold (say, 5 lines) or allocates/returns new object each 
time, i use getSomething(), otherwise its a property.

It can also depend on the logic. For example, in graphics 
programming, there are render targets and if I want to get a 
texture representing it I may do it in two ways:

.getTexture() and .texture

At least to me, .texture means that it would be the same object 
each time, possibly a reference to a private variable.
Whereas getTexture() implies to me that the function creates a 
new texture, copies pixel data and returns it.
Jul 22 2013
prev sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Monday, 22 July 2013 at 16:42:57 UTC, Land wrote:

 Thank you for the replies. So, what's the bottom line? Should I 
 use accessor methods or should I use properties? (I've read 
 quite a bit of the mentioned 500-post topic, by the way, but 
 I'm still not clear on what's the most logical step here)


Use properties. You'll find it more common in other D code. 
Whether you use a field or a method is up to you, I suspect using 
method will be more common.
Jul 22 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 22 July 2013 at 17:15:53 UTC, Jesse Phillips wrote:

 Use properties. You'll find it more common in other D code. 
 Whether you use a field or a method is up to you, I suspect 
 using method will be more common.


As multiple property threads have shown this is a _very_ varying 
preference among D coders. It it is mostly true for Phobos but 
out of it - no common guideline.
Jul 22 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Monday, 22 July 2013 at 17:27:02 UTC, Dicebot wrote:

 On Monday, 22 July 2013 at 17:15:53 UTC, Jesse Phillips wrote:

 Use properties. You'll find it more common in other D code. 
 Whether you use a field or a method is up to you, I suspect 
 using method will be more common.


 As multiple property threads have shown this is a _very_ 
 varying preference among D coders. It it is mostly true for 
 Phobos but out of it - no common guideline.


I disagree, those discussions were about  property, they had very 
little to do with accessor methods (getX setY). Most of the 
discussion was on how to add properties into the language where 
disagreement was around if optional parens were solving the 
problem.
Jul 22 2013
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 22 July 2013 at 18:08:15 UTC, Jesse Phillips wrote:

 I disagree, those discussions were about  property, they had 
 very little to do with accessor methods (getX setY). Most of 
 the discussion was on how to add properties into the language 
 where disagreement was around if optional parens were solving 
 the problem.


They had lot of information about concept of properties in 
general and how people do use them in other languages. There were 
plenty of different discussions, examples and disagreements - and 
I have read only 2 or 3 threads or all! :)
Jul 22 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 22 July 2013 at 15:07:29 UTC, Land wrote:

 I was just thinking about properties and to be honest, I don't
 like them all that much. There's no way to tell if it's a
 read-only or write-only property (right?), but getValue and
 setValue are pretty self-explanatory.


After many discussion I have come to personal decision to 
completely ignore properties as if they do not exist at all, same 
for optional parens - just sticking with old C++ naming habits. 
At least that is something obvious and that is not going to 
change in some future DMD releases.
Jul 22 2013