Re: [PyX-devel] A general comment

[Andre W. <wo...@us...>]

Hi,

On 27.07.04, Magnus Lie Hetland wrote:
> I guess in these cases a simple isinstance might be easier. After all,
> we *do* have multiple inheritance, so one could always just subclass
> the needed class as if it were an interface.

First of all, I agree to you, that we should use try-except clauses
instead of isinstance almost everywhere. But we do (maybe missuse) the
class structure and isinstance in one place, where I think its worth
to be discussed in order to make clear, whether its a design mistake
from the very beginning. I'm not so sure. Let me explain it a little.
It's related to the attribute system. Suppose you call the fill method
or the draw method of a canvas and provide some additional attributes
like colors, linewidths, linestyles, patterns, etc.

(Additionally, the fill and draw methods can take some decorators,
which might add other stuff (like arrows) and shorten the path (for
the head of the arrow and the like). BTW Jörg, Michael: we wanted to
restrict ourselfs to not really modify the original path anymore by
decorators, which are now called deformers. Did anybody the coding for
that? The decorated path should be simplified in that sense. We need
to come back to that issue at some point. Maybe in Basel, Jörg? But
back to the draw and fill attributes.)

So what we did is, we introduced a strokestyle and fillstyle class,
which is used as a mix-in to certain attributes. The idea is, that a
color can be used as a stroke as well as a fill style, while a line
width is usefull when stroking only. Once we mix-in the strokestyle
and/or fillstyle class, we can use isinstance to check, whether the
style is appropriate to be used at a given point. (Isn't that's what
Jim Fulton always says, that __implements__ is something else that a
position in a class hierarchy.) I know, that we created some
restriction here: you can't derive a class from, say, the line width,
which will not be a stroke attribute anymore. But I don't care (we
really don't need to take care). I think, at this very point, the
isinstance is the most simple check possible. We could define some
"ask-what-it-is" functionality on attributes as a whole, but I'm not
sure we really need this. (BTW: it is neither very complicated to
change this at a later point, nor would it be visible to the outside
world. So I can live this this issue quite well as it currently is --
independing from what you're telling me ;-).)

(As a side remark: The merging an clearing-functionality of the
attributes is based on isinstance as well ...)

> The reason I noticed this was that I saw plenty of isinstance() calls
> in the linear equation code -- might be inconvenient if one wanted to
> mix in multidimensional points between the variables and numbers it
> already knows about, because, basically, the "aren't allowed" in
> there.

Right. Don't take the isinstance code too serios right now. I added
quite some isinstance checks and assert checks to help me getting it
running properly.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/