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
|
- redefine the generic interface for dynamics, which is currently
|
||||||
in =generics=.
|
in =generics=.
|
||||||
|
|
||||||
I plan to implement the new dynamics interface as a classes, since
|
I plan to implement the new dynamics as a structure, from which
|
||||||
Typed Racket can now type classes. I didn't really like generics:
|
all the concrete dynamics of the objects will inherit. This will
|
||||||
they are quite cumbersome, and I think I can do more with classes.
|
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
|
People on Racket Users suggested using structures with fields
|
||||||
containing functions, but it does not seem to get me to my goal of
|
containing functions, but it does not seem to get me to my goal of
|
||||||
|
|
Loading…
Reference in a new issue