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

[Robin Becker]

In article <D2FFD3E4-A6C0-11D6-B433-00039345C610@darwin.in-berlin.de>,
Dinu Gherman <gherman@darwin.in-berlin.de> writes
>Robin Becker:
......
>Well, making it work is only a first step. ;-)
>
>What I don't see it what requirement there was to make all "standard"
>markers have the same class and be distinguished by a 'kind' attribute?
>Why not a subclass for each of these markers? Why should I want a
>DinuMarker of a 'Diamond' kind? Why should each marker know how to
>draw each kind of them?
>
>With a subclass there is no more need for a non-OO style 'kind' attri-
>bute, no need for a dedicated method, differently named for all kind
>of markers (which is not polymorphic), no more underscore ugliness,
>no more breaking the convention of underscored methods being private
>and not needed to be implemented in subclasses.
>
>The same kind of reasoning probably applies to widgets/flags.py.
>
>Dinu
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.
-- 
Robin Becker