@property - take it behind the woodshed and shoot it?

[Jonathan M Davis]

On Thursday, January 24, 2013 21:47:38 mist wrote:
> On Thursday, 24 January 2013 at 20:44:33 UTC, eles wrote:
> > On Thursday, 24 January 2013 at 20:26:50 UTC, mist wrote:
> >> On Thursday, 24 January 2013 at 20:20:42 UTC, Adam Wilson
> > 
> >> wrote:
> > I think the widest spread use case of a property is:
> > 
> > you start with a variable as memeber of a class, you write a lot
> > of assignment code, then you decide that you need to do some
> > more
> > extensive processing instead of simple assignment, and all that
> > without breaking existing code.
> > 
> > so, you transform the variable into a property.
> > 
> > of course, it could happen the other way around (converting a
> > function into a property/variable).
> 
> It is a wrong use case for a property. Necessity to change data
> assignment/access to call of function with side-effect is design
> error and should be fixed with programmers experience, not
> property hacks.

Being able to swap out a public variable with a function without having to 
change any code using it is arguably the primary reasons that property 
functions exist in the first place. Yes, making it so that the property 
function has a _side-effect_ is a bug, but replacing variables with property 
functions is not. A classic example of why it's useful is when you refactor a 
class such that a public variable becomes a calculated value such that it 
doesn't make sense to have a variable for it anymore. Instead of breaking all 
of the code that uses the variable by changing it a function, you change it to 
be a property function, and all of the code which used it continues to compile 
and work just fine.

D's properties need some work before that will really work properly (e.g. 
http://d.puremagic.com/issues/show_bug.cgi?id=8006 ), but it works just fine 
with property implementations in other languages (e.g. C#).

- Jonathan M Davis