[reportlab-users] Re: [reportlab-team] widgets/markers.py

[Dinu Gherman]

Robin Becker:

> well I see this as two approaches to the same problem. These markers
> were never intended as anything other than a simple marker type for
> lineplots etc. One could pollute the global namespace with dozens of
> Diamonds, FilledDiamonds,... Ellipse.... GBFlag, USAFlag etc classes or
> one can have fewer classes with a distinguishing attribute. Starting
> from either it's possible to get to the other.
>
> I chose this approach since it greatly reduces the total number of
> Classes of type Widget which is important when looking at lists of the
> things etc. I can imagine hundreds of different markers and (like
> characters in a font) they should be aggregated into a higher level
> construct.
>
> As for the kind attribute it at least allows for an explicit list of all
> markers/flags supported by the class or instance. Since the instances
> are polymorphic in the true sense, 'kind' is the polymorphism switch.
> This is important in those applications where computability is
> important. My BaizarreChart might want to cycle through a whole bunch of
> markers and it can do so using an explicit list. Otherwise it needs to
> use inspect like functionality to locate classes of type Marker.
>
> Nothing prevents anybody from deriving a class directly from Marker. It
> will then merely have to support size, strokeColor etc and of course
> draw. I don't think that kind is required when Markers are used.

I don't think you'll change your opinion, but these are weak ar-
guments for me. You get pollution only when importing * which is
entirely your own fault. The type aggregation is exactly what is
done by making all markers inheriting of Marker. And if you really
need an iterator over all created instances of some class, there
are Singleton-like mechanisms to do that...

Dinu