The Peculiarities of the Anoma Level Object System

Protocol Design
1

The Peculiarities of the Anoma Level Object System

The Object system that is in the works for Anoma Level (AL) is a peculiar to say the least let me first outline the features of our object system:

  1. It’s a true object system, meaning that Object Oriented in the William Cook sense 1. I.E. Objects only know themselves and they work only on message sends. However we do go further away from Cook in how methods themselves operate and specialize.
  2. The object system mostly takes a declarative form, meaning that we will have unification of objects (see 2 for a declarative OO system).
  3. Further our object system is mostly a functional one, we require tail calls 3, and mutation is an abstraction ontop of transition between multiple immutable objects (further work is required to see how this works in practice and protocols ontop).
  4. Methods do not live within a single object. Our system is not self/smalltalk like where methods belong with the object and are lookedup directly from a dictionary object message send. It’s more similar to CL’s applicable methods 4. Currently we are not in agreement where the methods live, other than there will be a standard place the system looks up for the default method to apply.
  5. We have multiple inheritance, and likely mixin style (:around, :after, and :before) parameters to methods. We may recontextualize the mixin style around aspect oriented programming advancements.
  6. Objects themselves have a validity constraint that determines if some instantiation of a class is truly a valid member of that class type (I.E. for the Integer Class [classes are meta objects, so the Integer meta object], we may confirm that the slot with data really has an integer and not a string. Creating a string integer would be rejected by the system and considered invalid).
  7. Methods also have validity constraints, this is akin to constraints in the declarative sense, but they can chose what kinds of objects they are applicable on.
  8. Methods can specialize on multiple objects.
  9. Methods defined on the Integer class can be applied to a completely unrelated class such as a String, however it will likely fail. Both actual integers pose constraints and the method imposes constraints, meaning that the method most likely fails to be applicable. However if the data have compatible constraints the method can effectively go off.
  10. Methods can be searched for. For example (+ 2 3) follows the applicable rules 4, however if we call (integer64:+ 2 3), then we are specifically declaring we are using the + defined for the integer64 class, which imposes constraints on the inputs and output sizes, whereas the first would most likely find bignum:+ which has less constraints (given that 2 and 3 are bignums and not integer64s).
  11. The object system will have a proper reflection point, in order to call something like (class-of some-object), reflect must be called (class-of (reflect some-object)) (we can have short hands but we must call reflect before going to the meta level).
  12. Having a reflect system lets us chose compilers in system, as before sending off an object between controllers we can talk about that at the meta level and even select the format (cairo resource, nock resource, risc0 resource. Or if to another local domain that is trusted just a serialization format for the object).
  13. Having reflect let us talk about information flow control in a principled way, as information flow is a meta property of the object.

Overall we have a very weird object system, it’s an odd fusion of CL and Smalltalk style Object Orientation. There is some unique aspects as well such as messages using the object inheritance chain being applicable to objects in a different inheritance chain! However for more specalized interfaces (such as an actor), we can simply add the validity to the object that it must be from the known set defined for it, meaning that this feature can easily be shutdown via the validity of particular objects.

Appendex

(1) https://pomf2.lain.la/f/3xpqmzlu.pdf
(2) https://logtalk.org/
(3) Why Object-Oriented Languages Need Tail Calls (eighty-twenty news)
(4) 28.1.7.1. Determining the Effective Method

3 Likes