> -----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 attempt to build a truly OOP hierarchy of geometric objects requires one to get to geometric fundamentals and that requires one to get down to projective ideas. Apparently there is in OOP theory a nearly irresolvable paradox of the relation of the circle to an ellipse in a OOP hierarchy. But from a projective point of view they are only the same object, viewed from different perspectives, i.e. they are projectively equivalent. So attempting to distinguish them as different levels of some hierarchy is bound to be problematic. It's really a geometric problem disguised as a programming one. IOW, attempting to fit these objects into an OOP hierarchy chain can only be an attempt to fit a round ellipse into a square circle, or vice versa ;) 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 saying much of anything about any particular triangle - and little is. Art _______________________________________________ Edu-sig mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/edu-sig