plan.org's managed classes arrived after NEXT.md's handoff was written, so a session reading the plan cold would take them as the next task. They are not: plan.org's own last line on them says nothing until struct, Handle and reload semantics work, and that belongs where the next task is named. Three findings from reviewing it that are not in plan.org. A generic function is a cell whose body is a dispatch table - adding a method later is the same problem the indirection cells already solve, so the expensive half of classes is built. Migration has to enumerate live instances, which makes the pool behind a generational Handle the only one of the three storage options that obviously supports it, rather than a free choice. And a numbered layout has to stay resolvable for migrate to dispatch on, which is the same retention rule as nothing is ever dlclosed. Also records the open question the class facility raises for conditions: whether a condition may be a class, what the hierarchy would buy, and the three costs - allocation on the signal path being the serious one. It wants answering before handler-case, since it decides whether handler matching has one path or two. Plus three nits in the new prose: float/int are not Flan type names, the place syntax was dotted, and the migration example set a slot the class did not have. The tag-word sentence said any was the only place one is paid, which Error and now a class instance both make false.
Description
Languages
OCaml
67.2%
Emacs Lisp
15.2%
C
10.4%
HTML
2.9%
Standard ML
2.8%
Other
1.5%