Adding an interface to existing classes

[Rick Johnson]

On Dec 22, 2:21 am, Spencer Pearson <speeze.pear... at gmail.com> wrote:
> I'm writing a geometry package, with Points and Lines and Circles and
> so on, and eventually I want to be able to draw these things on the
> screen.

...which is the main reason for creating a geometry package in the
first place!. I mean, imaginary points and lines are great if you are
a theoretical mathematician, but for the rest of us earthlings,
plotted pixels are the "in thang" now-a-days.

> I have two options so far for how to accomplish this, but
> neither of them sits quite right with me, and I'd like the opinion of
> comp.lang.python's wizened elders.
>
> Option 1. Subclassing.
> The most Pythonic way would seem to be writing subclasses for the
> things I want to display, adding a ".draw(...)" method to each one,
> like this:
> class DrawablePoint( geometry.Point ):
>     class draw( self, ... ):
>         ...

"DrawablePoint"? I suppose there is an "ImaginaryPoint" somewhere in
this API? Geez

> When the time comes to draw things, I'll have some list of objects I
> want drawn, and say
> for x in to_draw:
>     x.draw(...)

Seems reasonable. Not the fastest approach, but a good start for a
very high level interface.

> I see a problem with this, though. The intersection of two lines is
> (usually) an object of type Point. Since DrawableLine inherits from
> Line,

Why the hell is "Drawable" inheriting from Line? I would think that a
"Line" would be "Drawable" object and NOT vice-versa? Am i wrong?

> this means that unless I redefine the "intersect" method in
> DrawableLine, the intersection of two DrawableLines will be a Point
> object, not a DrawablePoint.

OMFG!

> I don't want to saddle the user with the
> burden of converting every method output into its corresponding
> Drawable subclass, and I don't want to redefine every method to return
> an instance of said subclass. I see no other options if I continue
> down the subclassing path. Am I missing something?

Yes, a proper object hierarchy and API it seems @_ at .

Spencer, i would re-think this entire project from the beginning. You
are trying to make an object out of everything. You don't need to make
an object of EVERYTHING. Ask yourself, what are the most basic objects
of a geometry library, and then report back to us your findings.

PS: I prefer option1 for these things as the OOP paradigm fits nicely.
I just hate to have modules of loose functions just lying about.