[racket-dev] Abstract classes

On Tue, Feb 7, 2012 at 11:50 AM, Asumu Takikawa <asumu at ccs.neu.edu> wrote:
> Hi all,
>
> Stevie and I have been hacking on an addition to the class system that
> would allow classes to be made abstract. Abstract classes are already
> used in the codebase, so the idea here is to make this a language feature
> rather than a pattern.
>
> e.g., the private editor% class that implements the editor<%> interface
> and is a superclass of text% and pasteboard% contains many methods
> defined with the body (void) that aren't meant to be called.
>
> We have an implementation on github here:
> https://github.com/takikawa/abstract-methods
>
> Currently, abstract methods can be defined with a new class clause:
>
>  (abstract m)
>
> that defines `m` as an abstract method. A class with at least one
> abstract method is an abstract class.
>
> Abstract methods are concretized using the `define/override` form.
> The idea is to be compatible with how people currently implement
> abstract methods as a design pattern (i.e., dummy method and an
> override).  This means that we could even go back and change existing
> classes, e.g., in the GUI libraries, to use the abstract form without
> breaking compatibility with existing clients.
>
> There are several design questions that we're still pondering:
>
>  * Should abstract classes be instantiatable or not? If so, abstract
>   methods would only fail when they are called. If not, `new` will
>   fail on an abstract class.  Currently our implementation disallows
>   instantiation of abstract classes.

I'd say to try this position and go around in the codebase looking for
abstract classes to see if it works with what we have.

One other abstract classe in the framework come to mind: the
frame:editor-mixin produces abstract classes.

>  * What should the syntax of the abstract clause be?
>   Matthias had the idea of specifying a method header to communicate
>   intent, e.g. (abstract [m x y z]) for a method `m` that takes
>   arguments `x`, `y`, and `z`.
>   This gets complicated if we support the full range of argument
>   options for a `define/public` (e.g., keywords).

What would you do with this information if you had it?

Robby