[plt-scheme] image-snip initialization

At Thu, 03 Aug 2006 16:15:15 -0400, David Richards wrote:
> (define Image-Snip%
>     (class* image-snip% ()
>       (super-instantiate ())))
> 
> (define Image (make-object Image-Snip% "/Users/dr/test.jpg" 'jpeg #f 
> #t))
> 
> This fails, but I really don't understand how or why.

As Robby says, some of the MrEd classes are a holdover from a previous
model of classes.

It bothers me a little that those classes are still unconverted. It
bothers me a lot that there was no way of making sense of the behavior
with the current description of the class system.

So, I changed the implementation so that classes like `image-snip%'
behave as if defined with `init-rest'. With that change, your program
works.

[The rest of this message just echoes Robby and Matthias.]

At Thu, 3 Aug 2006 18:09:09 -0500, Robby Findler wrote:
> At Thu, 03 Aug 2006 19:02:24 -0400, David Richards wrote:
> > Well it helps a little, thanks.  But using the PLT object system makes 
> > me feel like I'm collecting idioms like a philatelist collects stamps.  
> > [...]
> 
> , but there are some concessions to
> backwards compatibility (like new vs make-object vs instantiate)

I like the stamp-collecting imagery, and I feel the same way when I
learn a new set of APIs. Usually, the idioms have to do with patterns
of method calls, functions, uses of symbols or enums, etc.

In the case of MrEd, because MrEd and the class system are built for
each other, some MrEd idioms turn into parts of the class system. In
particular, there are leftovers in the class system where MrEd hasn't
been cleaned up enough. More significantly, though, the class system
ends up with many features that solve real design problems (which we
believe exist outside of MrEd).

At Thu, 3 Aug 2006 18:09:09 -0500, Robby Findler wrote:
> On Aug 3, 2006, at 7:02 PM, David Richards wrote:
> >   Shouldn't object systems should be designed not by piling feature on 
> > top of feature, but by removing the weaknesses and restrictions that 
> > make additional features appear necessary?
>
> We've tried to do that (and there will be a paper that makes this very
> argument about the mz class system, but I'll let Matthew tell you more
> about that one as he wishes)

To the degree that removing weaknesses and restrictions allows
composition of language constructs, the R5RS intro is a great bit of
guidance. It leads us, for example, to design a class system where
mixins can be expressed with `lambda', and where traits can be
expressed with mixins. That's what the forthcoming paper is about.

The R5RS intro also implies that we shouldn't have by-position class
initializers when by-name suffices; it's easy to agree.

Finally, the R5RS position could cast doubt on the many parts of the
class system that aren't just leftovers: override versus augment,
interfaces as well as classes, etc. (This may go beyond David's
concern, but it's something we debate from time to time, and I think
it's what Matthias has in mind.) We will continue to look for a more
orthogonal decomposition of PLT's class system. Another possibility,
though, when you have enough problems to solve, is that "removing
weaknesses and restrictions" is eventually superceded by "simple but
not too simple" -- and that's my guess.

Matthew