As discussed here, the shared and sleep flags on lunatik_class_t and lunatik_object_t are currently overloaded with multiple distinct responsibilities, which makes the semantics harder to reason about.
Specifically, class->shared currently controls three separate concerns:
- Whether
lunatik_monitorobject() is called during class registration (i.e., does this class support monitoring?)
- Whether
lunatik_cloneobject() is allowed for this class
- Which metatable
lunatik_setclass() picks for new object instances
Similarly, class->sleep has different semantics at the class level ("this class can have sleepable objects") vs. at the object level (the actual sleep mode of a given object).
Proposed refactor: Replace the individual bool flags with a capabilities struct (or bitfield) on lunatik_class_t
We could also add separate flags for clone and monitor (right now both are related to shared flag)
As discussed here, the shared and sleep flags on
lunatik_class_tandlunatik_object_tare currently overloaded with multiple distinct responsibilities, which makes the semantics harder to reason about.Specifically, class->shared currently controls three separate concerns:
lunatik_monitorobject()is called during class registration (i.e., does this class support monitoring?)lunatik_cloneobject()is allowed for this classlunatik_setclass()picks for new object instancesSimilarly, class->sleep has different semantics at the class level ("this class can have sleepable objects") vs. at the object level (the actual sleep mode of a given object).
Proposed refactor: Replace the individual bool flags with a capabilities struct (or bitfield) on
lunatik_class_tWe could also add separate flags for
cloneandmonitor(right now both are related tosharedflag)