Explain the new strategy for converting generics to Typed Racket.
This commit is contained in:
parent
ba8b9b4d98
commit
cdcee66b7c
1 changed files with 7 additions and 3 deletions
10
README.org
10
README.org
|
@ -48,9 +48,13 @@ interaction with Org-mode.
|
|||
- redefine the generic interface for dynamics, which is currently
|
||||
in =generics=.
|
||||
|
||||
I plan to implement the new dynamics interface as a classes, since
|
||||
Typed Racket can now type classes. I didn't really like generics:
|
||||
they are quite cumbersome, and I think I can do more with classes.
|
||||
I plan to implement the new dynamics as a structure, from which
|
||||
all the concrete dynamics of the objects will inherit. This will
|
||||
hopefully work like interface inheritance. The current plan is to
|
||||
start converting =networks= to Typed Racket, then starting the new
|
||||
module =dynamics= to fill in the blanks progressively by moving
|
||||
over bits of code from =generics=. The goal is to have an empty
|
||||
=generics= module at the end.
|
||||
|
||||
People on Racket Users suggested using structures with fields
|
||||
containing functions, but it does not seem to get me to my goal of
|
||||
|
|
Loading…
Reference in a new issue