Design Is Started

Just a quick update. I've got a pretty good start on the UML diagram for the foundation of the geometry module. You can get to it by following the My SymPy Workings link to the right or go to it directly by clicking here. This is just an initial, very basic diagram for the moment, and some things aren't really descried in the diagram. For example, Some things I have as methods but they might really be attributes fetched by an overloaded __getattr__ operator (eg, area for Polygons and Ellipses).

Any feedback on the current diagram, or suggestions for additions, would be great. Now, it's time for bed!

4 comments:

Unknown said...

Hi,

the diagram looks good. I myself think, that python is a great language for experimenting, thus I myself would just start coding immediatelly and see when I have something working. Then I play with the code, see if I chose a right or wrong path and then refactor it/change the interface, etc. But of course do it how you prefer to do it.

I just cannot really say, if your interface is good or bad, until I have a chance to play with the code. So I would suggest to try to solve the triangle problem as I wrote in the email and then see, if the resulting "user code" is nice and simple, and if so, then the geometry interface is good. Otherwise, it's bad. It's as simple as that. :)

Ondrej

Jason G said...

Haha, that's what I was planning on doing. I'm not someone to just jump in right away, but rather like to have a very rough idea of where to start. The diagram though, mostly encompasses the features (although I know of a couple I have missed).

The bigger thing I'd like to figure out is the set of test cases I'll use. I may work on that today or possibly start doing some of the code. It's probably better to wait a bit on the test cases just in case the interface gets changed somewhere along the way.

JimJJewett said...

I've sent some info by email, but I'll post some here for the record... yes, I agree that planning up front is valuable, but python is sufficiently lightweight that it can serve as a prototype language. Instead of saying that Point will have these methods and those attributes, you can just write


class Point(object):
position = None
def __eq__(self, other):
try:
return self.position == other.position
except AttributeError:
# not a Point, I guess
return False


then refine it as you go on. (For instance, you should probably inherit from the Numpy base instead of a blank object, and you will want something other than a class-wide None in position, but ... that lets you get your design out.

JimJJewett said...

(I'm still getting the hang of this blogging software. Let's see if this code looks OK.)


class Point(object):
....position = None
....def __eq__(self, other):
........try:
............return (self.position == other.position)
........except AttributeError:
............# not a Point, I guess
............return False