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. * 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). Any thoughts or suggestions? Cheers, Asumu _________________________ Racket Developers list: http://lists.racket-lang.org/dev
