Summary:
FlashJPEGDecoder gets called from ImageReadWriter with a RWBinaryOrTextStream (or sometimes a StandardFileStream) but is expecting a FlashFileStream in order to find nextByte method. I need a work around for this impossible state of affairs brought on by the unhappy reordering of subclasses brought on by my adding a new subclass to ImageReadWriter in trying to teach Scamper about X bitmaps.
Some of these streams define next ^nextByte others define nextByte ^next others leave it to their superclass.
I'm very confused, and would be grateful for help out of the maze.
Detail:
Today I spent many hours trying to figure out why I could not resume play with my XBMReadWriter subclass of ImageReadWriter. The only thing that changed was that I switched from the Sun at the office to the Linux box at home.
For some reason, every time I loaded my XBMReadWriter class, ImageReadWriter quit being able to understand gif files.
As near as I can tell, by adding the XBMReadWriter I have changed the order of subclassing such that 'ImageReadWriter formFromStream:' now does 'detect' in a toxic order:
ImageReadWriter formFromStream: grabs hold of FlashJPEGDecoder because it is the deepest JPEGReadWriter subclass.
FlashJPEGDecoder is sent 'understandsImageFormat' it has no such method and goes to its superclass for it.
JPEGReadWriter receives 'understandsImageFormat' it sends 'self next'.
FlashJPEGDecoder receives the 'next' message. inside 'next' FlashJPEGDecoder sends 'stream nextByte'
The stream handed to ImageReadWriter is not a FlashFileStream it has never heard of the nextByte method defined by FlashFileStream.
BOOM.
Polymorphism eats its tail and collapses upon itself.
Any suggestions how to route around this?
Interestingly, the error is most often NOT caught by a debugger, but ends up as TEXT in Scamper: "Message not understood: nextByte" in place of the image in the document morph. The lion's share of my time was spent in learning how to thin-slice my way through the debugger with self halt. such that the system would actually choke on the offending code in an observable manner. That time was not wasted, though. I understand rather a LOT more about squeak.
Word to the wise: Don't step the debugger across a call to a file readin sub-process. LaLa Land or core dump are the only observed results.
I would have had an easier time if I'd taken smaller bites on the problem, and learned how to call ImageReadWriter directly from a workspace. I know how to do that now too. :-)
-wdc
squeak-dev@lists.squeakfoundation.org