I believe we can satisfy this for a given type system. I want AL to support pluggable types in time. Something important is that the type checker must be a function in system, so if you have different type checkers with different properties that you can attach to methods, then you could in practice query for all implementers of the interface and it must satisfy the specific type check you care about:
Namely the images under section 5: Standardization of Application-related Data - #19 by mariari
I post some example queries from GT here, just imagine another filter for satisfying some property.
I mention these, as these are required to have a live system of anoma without having to define extra out of system constructs. Just a note on practical requirements that are important that we try to realize.
These protocols are specified to be exact, and we will want all the features and maybe a few extra protocols for our own specific needs. It’s good to get in the habit of understand how things like the MOP compose as we’ll want a similar design ethos to our own extra needs.
I mean, we should be able to add new methods to an existing object, we should be able to add new slots and have all objects in the domain be upgraded with the new values. Etc etc etc.
Literature which talks about upgrades:
- The CLOS/MOP spec
- Erlang upgrading mechanism (on_codechange)
- Urbit’s on_load
- I believe some smalltalk book (I don’t know which book of theirs off hand, maybe the blue book?)