[Edu-sig] Design patterns
ajsiegel at optonline.net
Sat Aug 20 04:15:41 CEST 2005
> -----Original Message-----
> From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On
> Behalf Of Kirby Urner
> Sent: Friday, August 19, 2005 8:30 PM
> To: edu-sig at python.org
> Subject: [Edu-sig] Design patterns
> Anyway, here's a design question: do we want to compute the angles and
> store them as properties at the time of construction, i.e. in the init?
PyGeo emphasizes dynamism.
So on the one hand I am anxious - for performance reasons - to push as much
processing as I can into __init__. IOW, start-up time for a construction is
much less a concern than the responsiveness when there is change, i.e. when
a point of the construction is picked and moved and all the implications of
that move needs be determined and all elements affected by it redrawn.
And exactly for the same reason, there are clear constraints as to what I
can in fact put in __init__. Everything intended to be dynamic needs to be
in methods calculated on the fly.
What I end up with to get decent performance is a patterns of registration.
Part of __init__ for any element is a process with registers it on a chain
of dependencies, so that when a point is in fact picked and moved the point
knows what other elements of the construction depend - directly and
indirectly - on its position and only those elements are recalced and
The moral of the story is, I think, it depends on what in more precise terms
you are trying to do.
The great fun of building PyGeo has been that I always had a pretty clear
idea of what I was trying to do. Given that, it seemed a process of simply
discovering the way to do it. That is as opposed to inventing the way to do
it. The way to do it was pretty much dictated by the intent of the project,
and was more and less sitting there. I have just needed to find it.
More information about the Edu-sig