Arthur wrote:
What beyond sugar for leaving off a () when trying to retrieve a value
from a method are we accomplishing by using properties? I have tended to
look at properties mostly an accommodation to those coming from other
languages which have something similar, but never as something that
-Original Message-
From: Kirby Urner [mailto:[EMAIL PROTECTED]
A weakness in the above design: we only check for violations of triangle
inequality in the constructor, yet allow changes to a,b,c through the API.
Among my list of unsupportable theories is one to the effect that any
PyGeo has a Triangle object, inherited from the Plane object. It exists
mostly for drawing purposes, as the portion of the plane enclosed by the
infinite lines connecting any 3 points. Since all Triangles are
projectively equivalent, in the context of PyGeo there is little to be
gained by
-Original Message-
From: Kirby Urner [mailto:[EMAIL PROTECTED]
Good point about all triangles being equivalent given projection. In
nailing down the angles, we've inadvertently defined a fourth vertex: the
point of view. Given we're talking four vertices, we should maybe rename
Arthur wrote:
As an API matter, I find myself liking the clue that () provides as to
whether one is accessing something designed be determined dynamically.
In general I agree with that sentiment.
I find myself leaning towards the option of making the use of properties go
away in PyGeo.
Though when we add another dimension, all tetras are projectively
equivalent. Part of why I can't adjust to a focus on a tetra that happens
to be regular in some way.
Art
Well, another way of putting it is: all tetrahedra are the same regular
one, except not because of viewpoints.
Kirby
-Original Message-
From: Kirby Urner [mailto:[EMAIL PROTECTED]
A lot of these lessons about robust software development come from group
or
community efforts. Some aspects of Python maybe don't much excite you
because you're primarily a solo coder (as am I much of the time).
I
