[plt-scheme] Class questions

> > Separate question... Is it possible to override the draw-* methods
> > (such as draw-line, draw-point, etc) ? If there was a class I could
> > use as a base then it would be clearer to me, howerver I'm not sure
> > how to create a derivative of a canvas device context. Let's say I had
> > the extended-canvas% class as shown above and then wanted to override
> > draw-line such that it wrote to the backing-store bitmap. It doesn't
> > seem right to add a method to extended-canvas% called draw-line since
> > the native draw-line operates on a device context.
> 
> I think you want to build your abstractions so they take a dc as
> argument. Then, either use the canvas dc, or use a bitmap-dc with the
> backing store in it.

"These aren't the droids you're looking for."

        Obi-Wan

;-)

OK, I'll re-think some of what I'm doing. In addition to backing store
I'd like to be able to associate a "transform" object with an extended-canvas
which is a mapping from user-coordinates to device-coordinates. So the
idea is to override the draw-* methods so that they honor the
specified transform if one exists. Now, I did notice the set-scale and
set-origin methods, which seem to be all that would be needed to do
simple user->device-coordinate transformations, but not general affine
transforms. However, there doesn't seem to be a way to get the y-axis
to point up, that is, I cannot set the y scale to a negative
number. If it really isn't possible to get that integrated with MrEd,
I can always make a new sheet% class that uses canvas% and dc% under
the covers.

I should also note some motiviation here. I've used canvases with
bitmap backing stores and done user->device coordinate transforms plenty of
times before, but they were always implemented as a set of functions
on top of MrEd, never well integrated with MrEd. I'm trying to learn
both class.ss and MrEd a little better and figured that integrating
these extra features as true class extensions would yield overall good
results. Afterall, I figured this is what the object system is for. I
know that doing a good job, design wise, of extending an object
hierarchy can be non-trivial and I'm sort of taking a trial-and error
approach. Or rather, I'm building something and then deciding whether
or not it looks and feels right.

Also, thanks for the class% example in the other note.

Ed