Kirby Urner wrote:
So I find that rejecting it as naïve is fundamentally unresponsive. Art
However in this case I don't think your views were rejected as naïve. On the contrary, your views permeated a sophisticated discussion of use cases, and design patterns more generally (s'been a rich thread) plus Scott sort of liked your using () to connote dynamism (I didn't).
This is close to what I meant. I dislike properties that don't behave as if they were attributes. That is, I'd like two accesses to the same property of a particular object to return the same value until the object has been "changed," and I don't like read access to a property to be a "real" change. There are three exceptions I allow in my personal aesthetic: * debugging code: All's fair for this case. Properties are _golden_ for allowing tracking things into a lot of code without changing that code. * instrumentation: Measurements can be accumulated about behavior, but shouldn't interact with normal operation. * performance: Achieving the same results with different performance is often the whole point of systems programming style programming. --Scott David Daniels Scott.Daniels@Acm.Org