Joseph Ferano 59e9392ec8 What the class decision changes for the next session
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.
2026-09-11 17:35:06 +07:00
2026-09-11 07:21:37 +07:00
2026-09-10 18:55:55 +07:00
2026-09-11 12:23:10 +07:00
2024-07-09 21:01:55 +10:00
2026-09-10 14:40:34 +07:00
2026-09-11 09:22:44 +07:00
2026-09-10 14:56:35 +07:00
2026-09-10 14:40:34 +07:00
2026-09-10 14:40:34 +07:00
2026-09-10 14:40:34 +07:00
Description
No description provided
MIT 7.5 MiB
Languages
OCaml 67.2%
Emacs Lisp 15.2%
C 10.4%
HTML 2.9%
Standard ML 2.8%
Other 1.5%