all objects - LeFreq/Singularity GitHub Wiki

Objects are encapsulations of CODE + DATA, plus a NAME. If you don't have these, you don't have an Object.

"All objects" (from front page) is perhaps a bit of a misnomer. The epistemology of the OS calls for 5 different, base object-types, each with their own, but related, API. These may derive from a common base, offering services such as getID,

The traditional "API" of objects is completely wrong. If you want encapsulation, you don't have an API at all. So Singularity and the GOOP standardize "API"s into +/- 5 object types. Programmers can derive from these and specialize with their own API, but this is shunned, as the architecture builds wisdom and re-useability by constraining the freedom of objects. Each type of object has it`s own keyword and must conform to a minimal API.

• class: standard objects, mentioned in the GOOP, needing to bring data in and out, using or processing it in some cognitively-complete, simple fashion. These are represented as colored spheres. (color: hue of the rainbow)
• container: container objects, adding indexing, containment, and possibly others. These are spheres with sub-objects within them. (It may be interesting to note that a node on the network is a container). (color white?)
• number: numeric objects, which have standard math operators and comparisons.
• inspection: (the +1) inspection objects (thanks Python!), which can inspect other objects, probably in the 3d visualization. These objects have a different API consisting of names, not symbols. Given an object name, they can query what attributes/variables it has and the inheritance heirarchy. XXXThis might be a better architecture than a TEST fucntion in the OS. These might be octahedrons in the visual model. (color: reflection)
• hardware: (the -1) hardware "objects". These are just named components that can be queried ("?", or HARDDISK(GETID).), read or written to. Cannot be cloned or run. (color: black)
• if the network ever becomes "self-aware", there may be a sixth type of object: self objects which will autorun a predetimined set of codes.....

For completion and because I don't know where to put this:

• data: does not send or receive data, but simply exist ("strings", numeric cells, structs, etc.). These are represented as rectangular forms in coordinate space. These are data. It is suggested that if the data needs changed, that it is better to remake the object, to show something has changed.

The standard class type has a run command, the hardware type either sits and waits for input and produces output when instantiated. Containers don't have run commands. Containers build on the basic class type and add a size method and [] operator. Other class should not try to follow this object API, so as to make it clear that they are different types of objects. Numerics, for example, shouldn't try to shoe-horn the >> and << operators to make addition or whatever. And inspection objects should just have a simple API to look at all the data (perhaps a run method). Hardware "objects" don't have an API at all. They are either emitters or consumers of data, (sources and sinks in network flow parlance), nothing more. The run command on a meta object is autorun upon instantiation.. probably.

STUB...Four dimensions of object interaction influence/pressure (will: a request to process (or modulate?) that doesn't violate any constraint), feeding (an agreement by design, single parameter), law and control (government: set of rules made by the app written as contract or inside the function/object), reactions to external events:

• influence: Hierarchies, through inheritance of type
• processing:Parameters, taking direct inputs
• in/out, modulating of functions, and the direct input of standard objects.
• list in/out, taking a list of homogeneous (simpler) types.
• list in/out, MapObject, returning a same-length list, transformed by the MapObject at each element.

All objects take simpler types than the object themselves. This means, that there is a type of polymophism in the object model which is normally shunned as it usually confuses the meaning of the program.

Iterator object do not exist. Instead the whole OS and object-model distinguish between two (three) dimensions of message-passing: ??a container being passed into an object is considered another dimension of message passing as now there is a potentially endless? string of data being passed??.

Inspection objects might help see what nodes on the network are misbehaving, for example, in the distributed visualization of the network and other items that maintain the integrity of the collective whole (purgatory, distributive file system).

When objects are deleted, their content spills out into the Soup, where it`s data (perhaps a table or database) can be reclaimed by other objects or the operating system itself. Biologically, there is a clean up crew which harvests spill data, but in order to duplicate this behavior of cell in the OS, it would take anotehr level of order that links all data between objects into a single graph.

---

See also:

• filters and decorators