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.

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

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

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)

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.

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.

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.

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.

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.

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! :)