[Edu-sig] Design Patterns

[Scott David Daniels]

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 at Acm.Org