Are properties actually all that good?

[monarch_dodra]

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