UniformObjectModel - LeFreq/Singularity GitHub Wiki
FIXME: XXXThis may change to a binary object model: classes that build-up form the bottom and classes that architect from the top (templates?). They meet up at some point to make an app. From the top, one might have an Application template that allows many different apps to use a common high-level suite of tools.XXXNO
Objects talk to one another though the standard messaging framework of >> and <<. Object control one another through inheritance. An object encapsulated within another object can abbreviate some of these messages by omitting the destination and input (they will be assume to be the parent object). At the console, "'My message' >>" will echo the text back to the user. In an object, "myData >>" will queue up myData to the parent.
NOTE: There is a major partition in the system between strings and numbers. The former should be messages, akin to audio connections to an organism, while the numbers are akin to << >>, and light/data. This should PROBABLY REMAIN ABSOLUTELY SEPARATED in the model.
A unified object model is a model to relate all objects to each other. Instead of a forest of unrelated objects, you have a complete ontology starting at some small set of abstract or simple objects, like DNA. One must specify both the upwards objects (supervisors) and the downwards objects A complete enough ontology would make a cybernetic organism in this analogy: a set of interconnected parts that include input (the senses), output (voice and motor), processing (the brain/body), and object security (immune system).
Python, for example, has an abstracted "object" object. But for us, it needs to have a bit more form to be usable. Just like the atom had to have the different elements to make chemistry. It is exactly like that, rather than a proton object with electrons as data.
This model borrows from biology (biomimicry) and how multi-cellular, cooperative organisms emerged out of radical competition. The object is the cell, while the app is the organism. Different objects/cells are active while the application completes its tasks or finishes its purpose. If biology is a close-enough analogy, object inheritance is hardly ever done except in apps that need very tight control over a very vertical stack of run-time activity because they've mastered the domain and it needs no further changes. The operating system might find a way to optimize such processes to eliminate the object overhead, otherwise, like in biology, there is very little reason to do so.
To see the OS as a meta-order of language itself. What is the atomic unit of storage and Although all expressions are composed of objects, like English, some "words" are verb objects and some nouns. So that a text of a book, a video file, and so forth will be noun/data objects
Types all have an identifier for parsing to subobjects. A 128 bit identifier would allow enzyme-type identification if the object didn't know how to process an object.??? Why wouldn't it know? Because structs don't have meta-data?
Objects can be initialized with a struct-type (or noun) object (like a file) to save time at object creation. An object sent to the initializer should be nearly as complex as the object itself, as a general rule -- something that the object might have created, for example. So a MP3Viewer object is. initialized. with an MP3Data object. The initializer of that object, deconstructs the data into simpler data which is used in the initializer of the sub-object. These should be automaticable, so that the noun-type struct has substructs, while the verb-type function switch/cases to subfunctions.
An application is a sentence, composed of a subject-verb-object("User writes letter").
STUB
In Python, a dict containing type:object key:value pairs for delegation.
A String can be passed to a Book, to hold it`s contents. Getstate returns the title of the book. A set of functions can be surrounding the contents to encrypt, lock (so can't be written to). Such a Book object, when run, outputs it's contents.
Some object don't need run? Like a lock object to protect the contents of the object.
Polymorophism is generally an suboptimal solution. Polymorphism works like this. Each object accepts one type, but big objects are composed of several smaller objects, so that the bigger object can delegate different inputs (>>) to its respective components (a switch/case type sieve).
There are at least 4 object types dilineated by a keyword: self or meta object which can query other objects and inspect them, container objects which can hold other objects, security or sentinal objects which can access hardware, ...
Standard objects have four functions and a single storage attribute (that could be a single, long string, for example for the text of Shakespeare)
So our fundamental object will have some methods: << (get), >> (put), ? (query-state), and % (clone) or 1/ (run)XXX. Add compositing (adding objects together to create larger objects, called "mashups") and you have a complete system for building hierarchies of loosely-coupled, modular, unified, and universally re-useable components -- reuseable because there's no programmer-specific mini domain language.
The object initialization (as might be used in a superclass (distinct from parent class)) is like the GI tract in an organism, while the in << and out>> methods are like the communications channels. The object can be reproduced % and it`s state queried which is like the waste organ -- use it too often and you're probably making your object wrong. Run flips the cell/object from edit state to running state. The initialization is like a complex food input, whose input then has to be broken down into constituent parts and then shuttled to subobjects to take and process.
A graphical window, for example might be composed of a text buffer object, menu object, and frame object. Keyboard input might go directly to the text buffer object in your application object, mouse STUBinputA user of the window, might use the >> (put) method to get the text output from a window object (because the window object must control that the cursor wraps at the screen boundary), but the programmer might also try to get the >> method of the text buffer object if it wanted to override the behavior of the outer object (for whatever reason).
The only thing not directly part of the unified model is hardware input and output. For this UPU (user io processors) might send in a complex data structure: FrameObject << MOUSEIN. This struct would be composed of a mouseevent (mousedown) and coordinates (x,y). Actual tracking of cursor and moving it on the screen would all be handled by the UPU and not bother the objects.
One could consider trying to find a linguistic partitioning for object groups (verbs, nouns, adverbs? prepositions?, …), much like human language. Objects are generally the nouns and the operators the verbs. Then what are the adjectives and adverbs, respectively?
Two dimensions of interaction:
- host environment, giving upwards/downwards: the apps identity itself (outside view) identifiable by the host environment (perhaps used as a title bar heading) and (?:)getstate (inside view) which gives some kind of scalar to the programmer (not necessarily another object).
- inter-object message-passing, giving in/out: >> and <<. 360 >> factors >> out:(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, ...)