search

Hypercosm / HIDL

Hypercosm Interface Description Language
https://hypercosm.dev/HIDL
0 stars 0 forks source link

[RFC] Object Model V2 #16

Open aDotInTheVoid opened 2 years ago

aDotInTheVoid commented 2 years ago

Object model

Their are 4 parts of the object model

Extensions

All HIDL code is based in extensions, which all live in their own file. Core (hypercosm.core) is tecnicly modeled as an extension, even though it is mandatory.

Each extension exists in a namespace, which may be nested a la java packages.

The offical hypercosm extensions exists in the hypercosm namespaces, eg hypercosm.core, hypercosm.asset_delivery

Each extesnions consists of a callset, and potentialy some objects and types.

Each extension has a handle, which can be found with hypercosm.core.get_extension_handles() The hypercosm.core extension always has handle 0.

Objects

An object is an opaque reference to some state on the other node. Each object has an ID, which is used as the handle. This means an object ID must be unique, and not overlap with the hanldes for extensions.

Objects have a callset, which is the methods that may be called by them.

To get an object handle, call a method that returns one. These will usualy be methods on the extensions.

OO programmers may model the callset of an extension as a singleton object.

TODO: How should we differenciate the name of an object type vs an object instance. Should we do class/object, or something else?

Objects cannot inherit. The methods that existed on the old object instance will now exist on the hypercosm.core callset

Callsets

A callset consists of methods and events. Both extensions and objects have a callset.

Handles

A handle is a 64 bit unsigned integer, ecoded as a vu64. A handle either represents an object ID, or the callset of an extension.

To make a call, the caller sends the handle they want to make the call on, and the method id for the call they want to make.

daeken commented 2 years ago

This looks great to me so far. I think this might be a good time to discuss the notion of object ID namespaces, though, and see if we want to make a change.

Currently, we use a vu64 for object IDs, and each side has their own object table (or two, more likely). That means that if an object is passed to one node and then they send it back, it's ambiguous whose object it really is.

I think we might want to switch to a vi64, where 0 is still the Root, but negative object IDs are ones created by the connecting node and positive object IDs are ones created by the connectee.

I don't think this is a necessary change, but I do think it removes a source of ambiguity that might come to bite us in the ass later.

aDotInTheVoid commented 2 years ago

Yeah, I think "whose object is this" needs to be specified in the IDL. I'm not sure if it needs to be specified by sign.

If we do do sign, I think we should prohibit id=0, and say root=+-1, because its would be weird to have one ambiguous ID