[racket-dev] Abstract classes

On 2012-02-07 12:17:18 -0600, Robby Findler wrote:
> That seems like an interesting thing to explore, but it is in a
> subtyping, not subclassing direction and probably is violated
> somewhere in our codebase. Overall, it seems to point to a larger
> redesign of the class system.

That makes sense.

> Also, I don't see too much value in the former if it is just a hint.
> Seems useful to have that information in the documentation, tho.

I definitely agree that a defabstract (or equiv.) form for documentation
would be useful. It may be more useful to go this route rather than
relying on the code to signify the intent of a method.

  ***

Incidentally, I went through and replaced all of the methods that just
call (void) in editor% with abstract methods as an experiment.

Only three abstract methods failed to be concretized (and thus text%
failed to instantiate): on-focus, set-snip-data, and on-paint.

Of these, on-focus and on-paint were actually supposed to be implemented
as (void) so that subclasses of text% or pasteboard% can rely on a
protocol of calling super from the overriding method.

set-snip-data, however, was only overridden in pasteboard%, suggesting
the (void) implementation should actually be pushed into text% from
editor%.

There was another problem though: many methods in text% and pasteboard%
were implemented to call super or call the inherited (void)
implementation. These had concrete implementations, but would error when
they tried to call the abstract supermethod.

That still left around 63 methods that could be made abstract safely
(well, at least 'safe' meaning DrRacket runs).

Cheers,
Asumu