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
