I believe we can do almost everything on your list using the declarative nature of purely functional objects, as exemplified here. Or at least, it’s a good basis for your ALO system.
Yes, the linked model is functional, using mutation of objects via polymorphic record updates (part of the type system).
- Methods are separated from the object’s representation (data structure) via an interface type. Their class is also separated from the object, but this one contains the method implementations.
- Here is an issue. The model for the example I shared does not support multiple inheritance. We need something more, in the direction of intersection types. So, this requirement needs to be investigated if you want that. I believe with support for simple subclasses it’s enough, I might not see the whole picture.
- Validity constraints can be baked into the objects functions and there is flexibility here in what you can do. In the example for resources, I mentioned, one can put an internal instance variable to track access to the object, so that one can check that kind of thing at the moment of using methods. Or, at the moment of creation, you can check that the parameters given, the components of the object, follow a particular specification. I’d actually say, we simply use refinement types for this purpose.
- Methods can specialise on multiple objects via subtyping of interface types.
- Numeral 9 might be problematic. Failure semantics need attention, and the linked model does not currently support them.
- Numeral 10. We can write a type inference algorithm for this, most likely. Or it is out there already, probably.
- Numeral 11. We can extend the model so that another field, hidden in the object representation, captures an optional class object, which can be returned via a method. That needs to be included as part of the interface type when defining the class for those objects.