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