Re: [racket-dev] Abstract classes
On 2012-02-07 12:01:10 -0600, Robby Findler wrote: 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. That's a good idea. I can look into that. One other abstract classe in the framework come to mind: the frame:editor-mixin produces abstract classes. Creating abstract classes at runtime is a neat use-case. What would you do with this information if you had it? We could either just let it be a hint for the programmer or actually check that concrete implementations match the signature. I think Matthias had the former in mind, but either way is an option if we had this. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Abstract classes
On Tue, Feb 7, 2012 at 12:14 PM, Asumu Takikawa as...@ccs.neu.edu wrote: One other abstract classe in the framework come to mind: the frame:editor-mixin produces abstract classes. Creating abstract classes at runtime is a neat use-case. What would you do with this information if you had it? We could either just let it be a hint for the programmer or actually check that concrete implementations match the signature. I think Matthias had the former in mind, but either way is an option if we had this. Probably you wouldn't just do this for abstract methods, you'd want to change how define/public and define/override interact too. 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. 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. Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Abstract classes
On Feb 7, 2012, at 1:17 PM, Robby Findler wrote: 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. The implementation of the template hook pattern is a good example of abstract methods. A programmer who wishes to extend a class can either search the existing abstract class for all uses of the method and infer the right signature from that or the abstract method signature can tell the programmer what is expected. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Abstract classes
On Tue, Feb 7, 2012 at 12:54 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Feb 7, 2012, at 1:17 PM, Robby Findler wrote: 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. The implementation of the template hook pattern is a good example of abstract methods. A programmer who wishes to extend a class can either search the existing abstract class for all uses of the method and infer the right signature from that or the abstract method signature can tell the programmer what is expected. We have semicolons for comments already, no? Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [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 _ Racket Developers list: http://lists.racket-lang.org/dev
