@property as proposed in various DIPs, my attempted use and what I think of it

[Rob T]

Here's a C# link providing a definition of property

http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx

The C# implementation appears to fit closer with the namespace 
concept that had been proposed as solution to the property 
question, it is clearly not the same thing as the @property 
concept.

In the C# case, it may be a bit clearer when to use the property 
construct because in one shot you are defining both the variable 
instance and the way it is accessed, i.e., it may help somewhat 
with organizing your code, if there's scoping rules restricting 
access, that may help too.

In the D case, you must always define the variable instance 
outside the property scope, and then create a getter and setter 
for it separately. This is the usual way of doing things, with 
the only exception that when tagged with @property you can use 
the assignment syntax, so for the most part its only a question 
of what calling syntax is more convenient to use, assignment or 
regular function call syntax.

I can see an advantage that would make the situation a whole lot 
clearer. If internal to a stuct or class, you are accessing the 
local member variable directly, but later decide to wrap it so 
that it cannot be accessed directly (unfortunately this is 
impossible in D because of the way scoping works), you could 
rename the variable and wrap it into a property, and all your 
internal code will continue to work (but this depends on what you 
were doing with it).

Externally, I never make variables directly accessible 
(unfortunately in D this is not 100% possible due to scoping 
rules, eg private has no effect inside a module), so there's not 
much value to the property concept in my case because I'll only 
very rarely switch from a variable to a function wrapper. For me, 
I have to decide if the assignment syntax is more convenient or 
not, and that's all I have to go with when making a decision.

It would be far more useful to have a namespace implementation, 
because then I could 100% hide access to a variable, and that 
would make using such a facility much more clear, ie., it becomes 
a question of accessibility vs a matter of purely syntactic taste.

Without a clear purpose behind it, the @property concept buys me 
virtually nothing but syntactic sugar, except in the rare case 
where I may want to wrap a variable into a function after using 
it directly for a while, but even that is weak because the 
wrapper is a very leaky one, i.e,, you cannot 100% enforce access 
to go through the getter and setter from inside the struct and 
the module where it is used, and it does nothing in terms of 
helping me to define the wrapper scope, ie. there's no 
organizational advantages of grouping things together under one 
wrapper, and my code looks the same no matter if I use property 
or not.

In summary, it seems to me that where there is an advantage, it's 
very weak and very rare, so for the most part it's a feature that 
boils down to if I want to use the assignment syntax or not. I 
don't think that was the intention of @property, but that's how I 
see it.

For me, the optional approach is more flexible and does the exact 
same job as @property proposal. I can easily wrap a variable 
without specifying @property and get the same job done, and I can 
choose which syntax is more convenient at a later date and change 
it depending on the context.

If you want a more clear case for properties, then limiting 
access through scoping should come into the equation, as well as 
giving the programmer a better means to structure and organize 
the code around wrappers. @property does not help with any of 
this.

My opinions are based on actual attempts to use @property in 
production code and I found little use for it.

Have you tried to use it under real world situations?

--rt