# Questions I want to see researched

**URL:** <https://forum.anoma.net/t/questions-i-want-to-see-researched/1181>\
**Category:** Protocol Design\
**Created:** [February 13, 2025, 9:02am UTC](https://forum.anoma.net/t/questions-i-want-to-see-researched/1181 "2025-02-13T09:02:13Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\
**Post date:** [February 14, 2025, 10:42pm UTC](https://forum.anoma.net/t/questions-i-want-to-see-researched/1181/6 "2025-02-14T22:42:46Z")

</div>

> [@mariari](#):
>
> Glad you asked, I will take my definition mostly fromthe paper above along with minor clarification, the paper takes a denotational approach.

Thank you for the paper, I found it a clear, helpful, and entertaining read. I have never seen that definition of objects before, but it makes a lot of sense.

> [@mariari](#):
>
> - Objects only know of themselves (they are _autognostic_)

Just as a note, the resource machine – as it stands – does _not_ enforce this, resources are able to inspect the representation of other resources involved in the same action. They do not, however, have to – so an object system written on top of the resource machine could enforce this restriction.

> [@mariari](#):
>
> Objects are higher order values (it is the same as passing around closures!). This is often referred to as late binding or dynamic binding.

I do not think that this will be a problem, but I will note that the resource machine does not allow us to escape the fundamental efficiency tradeoffs of late binding.

> [@mariari](#):
>
> Objects use interface abstractions for their interface (not type abstraction, I.E. if we have a `set`, we can have a set object contain many different `types` of Sets. See the papers definition of Sets for an example, I can also post my prolog code if so desired). Thus it is to say object interfaces do not prescribe a specific representation for values.

I think that this is the main part that we need to figure out (with respect to how to implement objects on the resource model). This question is related to the question of “standardized resource semantics” discussed [here](https://forum.anoma.net/t/standardization-of-resource-data-label-and-value/842/5), which I think we could alternatively call “methods with properties”.

For example, we want to be able to define an interface (class?) with a view function:

```auto
class OwnedResource r where
  owner : r -> ExternalIdentity

```

and the property that the resource cannot be changed in any way that the owner has not explicitly authorized (which the resource logic has to “prove” in some sense, see the linked thread for further context). Having interfaces with _provable_ properties also seems to me like it solves a major challenge for object-oriented programming which is mentioned in that paper:

 ![Screenshot 2025-02-14 at 23.14.17](https://europe1.discourse-cdn.com/flex013/uploads/anoma1/original/1X/ac3a076a690add307f5efb5cee3992ea920b3046.png)

This is basically the same problem as the one I describe in that thread, and the ideal future solution which I propose there is no more and no less than a distributed-operating-system-compatible form of a behavioral specification: in our case, a specification of how the state of the system itself can evolve over time, which is a little different than the cases considered in the paper. One might say that our objects are _persistent_.

In terms of the question of mathematical representation discussed in the paper, the resource machine should be perfectly capable of representing structures by their characteristic functions, although it doesn’t change the tradeoffs of that representation (e.g. the impossibility of iterating over sets represented by characteristic functions). This will perhaps make the work of solvers more complex (as compared to an algebraic representation), but it will also perhaps allow different (and perhaps at times more efficient) formulations of CSPs, I’m not sure yet.

* * *

As for the MOP:

> [@mariari](#):
>
> - We should support inheritance, but it ought to be customizable by the user

I think this is purely a “programming system choice” and is fully compatible with (but not implemented by) the resource machine.

> [@mariari](#):
>
> - We should be able to reflect on every part of the object

This sounds like more of a question of practical engineering and tooling. Seems possible to me.

> [@mariari](#):
>
> 1. Objects should redefinable within a domain (reflection will help with this)

I do not understand this requirement, can you further define or link to what you mean here?

* * *

One further thought: I would consider objects _as they are defined in this paper_ to be purely a form of _data abstraction_, not a computational model. Contrast this to our concept of engines (as defined in the specs), which _is_ a computational model and _is not_ opinionated about the form of data abstraction. It is indeed a computational model that features sending messages around, which may sound superficially similar to “sending messages to objects”, but to me the choice of computational model and the choice of a form of data abstraction are independent. It may be the case that particular forms of data abstraction are more or less efficient to implement on particular computational models, but I don’t think this will matter, because the principal constraint in our choice of computational model is correspondence to physical reality, and that constraint is sufficient to fully determine the contours of the engine system.

---

_[View the full topic](https://forum.anoma.net/t/questions-i-want-to-see-researched/1181)._