On Wednesday, 30 January 2013 at 04:39:13 UTC, Adam D. Ruppe wrote:
> There's times when a member variable manages its own invariant and any of its values is valid for the containing class, in which case the container doesn't need to further restrict access to it.

But yes, there are times, when a public member variable, which encapsulates its own data, is truly designed as a part of the interface, in which case it doesn't need to be encapsulated any further.

On Wednesday, January 30, 2013 05:57:14 Jesse Phillips wrote:
> It seems at least some members for @property feel that currently functions are being annotated with @property that shouldn't be.

The prime example of that would be save.

- Jonathan M Davis

On Wednesday, 30 January 2013 at 04:57:15 UTC, Jesse Phillips wrote:
> I don't agree with the argument that properties provide a convince to identify low overhead access. While I'm not experienced in this area, profile code should indicate where performance is poor, it would be bad to assume "that looks like a field, so it must not be where the performance is bad."
>

Yes, this is true, like always. Even when property isn't involved.

Fectching memory that isn't in cache anymore is typically 200-250 CPU cycles on modern x86 architecture. Getting that from a register is immediate. Accessing a variable has unknown cost, and only profile can reveal the truth here.

Considering that property/function have some importance in regard of performance is in complete contradiction with how computer and code actually work now.

The difference is semantic. In case of property, you think data, in case of function, you think action.

On Wednesday, 30 January 2013 at 05:07:15 UTC, Jonathan M Davis wrote:
> On Wednesday, January 30, 2013 05:57:14 Jesse Phillips wrote:
>> It seems at least some members for @property feel that currently
>> functions are being annotated with @property that shouldn't be.
>
> The prime example of that would be save.
>
> - Jonathan M Davis

rehash, dup, length (as a setter), the list goes on and on.

On Wed, Jan 30, 2013 at 06:22:05AM +0100, deadalnix wrote:
> On Wednesday, 30 January 2013 at 04:57:15 UTC, Jesse Phillips wrote:
> >I don't agree with the argument that properties provide a convince to identify low overhead access. While I'm not experienced in this area, profile code should indicate where performance is poor, it would be bad to assume "that looks like a field, so it must not be where the performance is bad."
> >
> 
> Yes, this is true, like always. Even when property isn't involved.
> 
> Fectching memory that isn't in cache anymore is typically 200-250 CPU cycles on modern x86 architecture. Getting that from a register is immediate. Accessing a variable has unknown cost, and only profile can reveal the truth here.

+1. Too many C programmers (including myself) have preconceived notions about what is efficient and what isn't. Unfortunately, we're wrong more often than we'd like to admit. When we actually run the profiler and get real profile data, it often points to hotspots that are far, far away from where we thought they were. We inherited this premature optimization mindset from the CPUs of the 70's and 80's; today's CPUs have far different performance characteristics, and our preconceived notions are mostly all wrong.


> Considering that property/function have some importance in regard of performance is in complete contradiction with how computer and code actually work now.
> 
> The difference is semantic. In case of property, you think data, in case of function, you think action.

+1. The voice of reason.


T

-- 
I'm still trying to find a pun for "punishment"...

On Wednesday, 30 January 2013 at 05:22:06 UTC, deadalnix wrote:
> On Wednesday, 30 January 2013 at 04:57:15 UTC, Jesse Phillips wrote:
>> I don't agree with the argument that properties provide a convince to identify low overhead access. While I'm not experienced in this area, profile code should indicate where performance is poor, it would be bad to assume "that looks like a field, so it must not be where the performance is bad."
>>
>
> Yes, this is true, like always. Even when property isn't involved.
>
> Fectching memory that isn't in cache anymore is typically 200-250 CPU cycles on modern x86 architecture. Getting that from a register is immediate. Accessing a variable has unknown cost, and only profile can reveal the truth here.
>
> Considering that property/function have some importance in regard of performance is in complete contradiction with how computer and code actually work now.
>
> The difference is semantic. In case of property, you think data, in case of function, you think action.

Yes, very good points. We're likely optimizing away for little to no gain most of the time, and maybe even making things worse not better in some cases.

--rt

On Wednesday, 30 January 2013 at 03:02:38 UTC, deadalnix wrote:
> On Wednesday, 30 January 2013 at 00:26:11 UTC, q66 wrote:
>> It deeply disturbs me that people even take the original post seriously.
>
> Well, you may give some arguments instead of no, just no, to convince people.

It just gives another meaning to foo.bar, and ENFORCING camelCase by the language while lowercasing shit is just horrible. Anyone with a slightest trace of language design sense realizes that.

On Wednesday, 30 January 2013 at 02:15:09 UTC, Rob T wrote:
> Even with @property restrictions, I still don't think it will work as expected. For example, if the variable is a struct, then you have to disallow operations on the struct from outside.
>
> Example:
>
> struct Y { int a; }
>
> struct X{ @property Y y; }
>
> X x;
>
> x.y.a = 4; // <- this has to be illegal!
>
> Reason?
>
> struct X{
>
>   Y _y;
>
>   @property Y y{ return _y; }
>
> }
>
> // this won't change _y as it did before.
> x.y.a = 4;

Somehow I had missed this post. So, we can bury the idea of restricting the access to a public member variable by making it illegal to take the address of it. And as long as it is possible to take the address of a public member variable, it is possible for the end-user to by-pass all encapsulation that you might later on add over that public member variable. For this reason, my logic says, it is impossible to invent such an implementation of property concept that would make it possible to first put in a public member variable and later on encapsulate it *without* changing the interface.

On Wednesday, 30 January 2013 at 12:04:31 UTC, TommiT wrote:
> [..] it is impossible to invent such an implementation of property concept that would make it possible to first put in a public member variable and later on encapsulate it *without* changing the interface.

And frankly, I think it's a good thing. Because this way we can add to D's documentation: "NOTE: properties are *not* inter-changeable with public member variables", and thus, actively discourage people from writing un-encapsulated interfaces which expose public member variables.

On Wednesday, 30 January 2013 at 12:11:30 UTC, TommiT wrote:
> Because this way we can add to D's documentation: "NOTE: properties are *not* inter-changeable with public member variables", and thus, actively discourage people from writing un-encapsulated interfaces which expose public member variables.

The moral of the story:

We should all stop thinking of properties as data, and start thinking properties as functions that you call with a data-like interface.

The value of properties is in clearer semantics:
Separate accessor and mutator are tied together very loosely, that is, only by the similarity in their naming: getSomething, setSomething.

Whereas property getter and setter have the same name, and thus are semantically un-ambiguously tied together.