swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Subclassing (again) & Protocols [Swarm 1.2, Solaris 2.5]


From: Gary Polhill
Subject: Subclassing (again) & Protocols [Swarm 1.2, Solaris 2.5]
Date: Wed, 04 Nov 1998 12:46:12 +0000

OK I should have learned my lesson from trying to subclass
off the Array class, but this time I thought I could get away
with it. I am trying to subclass from the Colormap class.
You're going to ask why, and I'll tell you, but not now.

My first question is: why does the compiler complain that
my subclass of Colormap does not follow the Colormap protocol?
My understanding is that if a class implements a protocol,
then it promises to provide a set of methods. By definition,
a class which inherits from another class inherits all of its
methods. Therefore, if I subclass from a class which implements
a protocol, then surely this subclass implements all of the
methods required for the protocol by inheritance. Where is
the flaw in this argument?

Moving on. In order to subclass from Colormap, I needed to
include its header, and so put in my subclass (which I called
DBColormap) header file the line #import <tkobjc/Colormap.h>.
The compiler complained that it couldn't find the X11/..., PNG,
ZLIB and XPM header files. So (and this is where I should have
got really suspicious) I modified the Makefile.appl INCLUDES
line as follows to pick up any includes that I wanted to do
for my app.

INCLUDES = -I$(includedir) $(APPINCS)

(And then in my app's Makefile I had

APPINCS=-I/usr/openwin/include etc. etc.

-- BTW I think it would be nice if the default Makefile.appl
enabled users to include their own libraries and header files
in this way, picking up an APPLDFLAGS variable in the app
Makefile as well, if present.)

make had the following to say about my modifications:

gcc -c -Wno-import -g -O2 -I/home/swarm/swarm1.2/sunos5.5/swarm/include
-I/usr/openwin/include -I/home/swarm/needed/sunos5.5/xpm/xpm3.4h/include
-I/home/swarm/needed/sunos5.5/png/png1.0.1/include
-I/home/swarm/needed/sunos5.5/zlib/zlib1.1.2/include EZBar.m
In file included from
/home/swarm/needed/sunos5.5/png/png1.0.1/include/pngconf.h:128,
                 from
/home/swarm/needed/sunos5.5/png/png1.0.1/include/png.h:112,
                 from
/home/swarm/swarm1.2/sunos5.5/swarm/include/tkobjc/internal.h:19,
                 from
/home/swarm/swarm1.2/sunos5.5/swarm/include/tkobjc/Colormap.h:17,
                 from DBColormap.h:20,
                 from EZBar.h:13,
                 from EZBar.m:22:
/usr/include/string.h:45: conflicting types for `swarm_strchr'
/home/swarm/swarm1.2/sunos5.5/swarm/include/misc.h:23: previous declaration of
`swarm_strchr'
make: *** [EZBar.o] Error 1

The question is, is there any way of including the interface
to the Colormap class without having to include X11, PNG, ...
stuff as well? (I've tried <gui.h> -- it didn't work.)

I have a nasty feeling I'm going to be told I should be
doing this a different way, so let me explain myself, as
promised earlier.

I wanted to do a bar chart, not a histogram, so I hacked the EZBin
source to give me an EZBar class. I had this working, but got greedy.
I wanted the bars to be coloured in a way that would match up with
a discrete2d display I have. EZBin (and hence EZBar) create their
charts using the Histogram class, which takes an array of strings
containing the colours for each bar -- either as a colour in rgb.txt,
or in the format "#RRGGBB" in its setNumPoints:Labels:Colors:
method. The Colormap class can currently return a PixelValue (which
is typedefed from unsigned long or some such), which I don't know how
to convert into "#RRGGBB". (Of course, it'd be nice if Histograms took
an array of PixelValues for the colours.) Since the Colormap class
creates these strings anyway, I thought I would create a subclass
that stored them, and could be asked to retrieve them. (Basically
all the setColor methods call the setColor:ToName: method, which
I over-rode to store the Name argument in an array indexed by the
Color argument.

At the end of the day, should I only ever consider implementing
classes that inherit from Swarm or SwarmObject?


Thanks,

    Gary Polhill


--

Macaulay Land Use Research Institute, Craigiebuckler, Aberdeen. AB15 8QH
Tel: +44 (0) 1224 318611               Email: address@hidden




                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]