Re: Python Programming: An Introduction to ComputerScience

In sum, when writing geometric objects to output media, there's a way to go wherein anything specific to the medium is saved to the "writer" object, while anything purely geometric, and common to all media, is saved in the geometric object. The pure geometry is kept separate from the messy details of I/O.
If I am following you: In PyGeo the geometric "reality" is separated from the drawing, for a number of reasons. My Vpython objects, which draw, are related to my geometric objects which "are", but they are not those objects themselves. Partly because of the corner cases. If, say, my point defined as the intersection of 2 lines moves off to infinity, I have a drawing problem. I cheat and put it, well, very far away - but not so far away as would create havoc in the rendering. The point itself knows where it really is - at infinity. 'Til now, I have been using Vpython to output to Povray. But am moving toward each geometric object having its own method to output itself to Povray format. And if VPython goes away, I can always plug in a different rendering system without changing anything too near the core of what PyGeo is. Think it is sensible, and standard, design practice for this kind of thing. Art

'Til now, I have been using Vpython to output to Povray. But am moving toward each geometric object having its own method to output itself to Povray format.
This would be a different design pattern from the one I've described. In the implementation I'm describing, the geometric object will never know anything about Povray or VRML or Vpython. It doesn't output itself, but gets passed to a "writer" which knows how to interrogate it for the necessary information. Here's an example: #===== class Vector: # note: no draw method def __init__(self,x,y): self.x = x self.y = y #===== class Povray: def __init__(self,filename): self.outfile = filename def point(self, v): # v is a vector (above) #<write stuff to self.outfile in POV-ray syntax> def edge(self,v0,v1): # v0,v1 are vectors (above) #<write stuff to self.outfile in POV-ray syntax> def polygon(self,vlist): # vlist is a list of vectors #<write stuff to self.outfile in POV-ray syntax> #===== class VRML: def __init__(self,filename): self.outfile = filename def point(self, v): #<write stuff to self.outfile in VRML syntax> def edge(self,v0,v1): #<write stuff to self.outfile in VRML syntax> def polygon(self,vlist): #<write stuff to self.outfile in VRML syntax>
And if VPython goes away, I can always plug in a different rendering system without changing anything too near the core of what PyGeo is. Think it is sensible, and standard, design practice for this kind of thing.
But if you take away VPython, will your objects still have a lot of draw methods that are now irrelevant. From your description, it sounded like you were doing something like: #===== class Vector: def __init__(self,x,y): self.x = x self.y = y def drawPOV(self, filename): #<write stuff to filename in POV-ray syntax> def drawVRML(self, filename): #<write stuff to filename in VRML syntax> def drawTk(self, canvas): #<write stuff to canvas in real time> In this case, the Vector object has a lot of knowledge about specific output formats. In the former case, the format writers squeeze objects like oranges, to get the "juice" out (just numbers, basically). The writers then independently translate this "juice" into their own respective media. Kirby PS: If I did add a draw method to Vector (above), it would have the form: class Vector: # note: no draw method def __init__(self,x,y): self.x = x self.y = y def draw(self, writerobj): writerobj.point(self) i.e. it's still the case that all POV-ray specific info is hidden inside the passed-in object: v.draw(povobject) and v.draw(VRMLobject) would result in different syntax because of the parameter objects, not because of the vector object. Kirby
participants (2)
-
Arthur
-
Kirby Urner