GOOP - LeFreq/Singularity GitHub Wiki

NOTE: This document is superceded somewhat (see this page), but the essence remains: all types should conform to a unified architecture, much like Maxwell's 4 equations dictate all the macro behavior of your world.

Here begineth the lesson:

Objects are discrete encapsulations of code + data contained and labeled with a unique LABEL. Objects that don't have data are called lambdas or mix-ins. Objects that don't have code are called arrays, structs, or "tables" for you DB users. At the smallest granularity, these are hardware registers. LISP, under this definition, is composed of objects. But without a label, don't call it an "object". If your input type is the same as your output type, you have a function: don't use an object. (Note: If one is making a simulation, then they need to add a new object model inside this one. This model is for "basic" data: originating and relating to the real world.); At the highest level, you give these things names and they become a bona-fide object.
All generic objects must do one thing, or have a single state variable. If an object holds multiple states, the object should be broken up into multiple objects because, inevitably, someone will want to do something with only part of it (precision-domain principle. If one of your generic objects doesn't do something, don't make it an object. Complementarily, if an object doesn't have a state or variable, it is not an object. Refer to rule #1. This rule may not apply to the other object types. Containers don't need to do anything (spill their contents?), for example. Inspection objects might.
Objects compare themselves for equality by comparing states and object type.
The object domain (or DataEcosystem) is a burgeoning field, but there should be noted only two, opposite kinds of object interactions or relations: consumers-of-objects and producers-of-objects. The latter I'll term programmers (sometimes: higher-level "applications") and the former users. Users are sometimes programmers, and vice versa, but they're completely opposite specializations and relationships to the machine. The object sits in-between, serving both, so there is no canonical way to refer to a object syntactically in some hierarchy (uppercase vs. lowercase, e.g.), as there will always be more than one kind of relationship to any object within a object ecosystem (some will be for users, some inside other objects). Each user may structure their objects in a tree, but ultimately, they exist outside of it as part of a graph: flat, reuseable, modular, independent, and conformant to the system standard.
It is a grave sin to attempt great ontologies of objects starting with some abstract base class and building towards specialization, only to end with a single object at the top again (your application). Start with concrete base classes (like <int></int>) and simple utility objects that can be composited together and let those hierarchies grow in the other direction (like an object Rational holding an abstracted concept for number that hides machine limitations): the application the user sees -- not your personal relationship to the code. Grasshoppper: just as a raindrop is said to form around an impurity in the air, form your application around the machine types and re-useable utility objects. Container objects are, then, simply part of your toolchest.
There are only a very few [all]] to start building your application: standard objects, container objects, and inspection objects that you build your application with. Numerics and hardware are other specialized use-cases.
Users should be spared programmer idiosyncrasies as much as possible. That means all objects in the ecosystem should conform to a uniform syntax for data passing, rather than learn custom APIs for every object, and objects must know what to do with data passed in or asked out. Just as there are only 26 letters to handle the entire corpus of English text, there are only 4 functions needed to handle every object need: query-object (?), clone-object (%)(push this up to new ABCs?), receive (>>), and send (<<). This is for the generic, standard object. These combine and interact to form a fractal hierarchy, ending in the host environment where the user/programmer can also pass data into (">>") and out of ("<<") their host environment (a sort of "meta" object) or query ("?") that environment to get system version and perhaps enter the help system, much like an interpreter. XXX: This is out-of-date: clone-object can be moved out of the object and into the host environment.
At the two extrema of any object interaction are the input and output nodes of the object system itself. Like STDIN and STDOUT for keyboard and text I/O (respectively), you have a label for each point of data going in or out of your system (whether it's a GUI window, another peer on the network, or your mouse input).
Data I/O to the right with the << operator sends it upwards in abstraction, towards parent objects and users themselves. Data XXXFIXME
XXX redo: 2 hierarchical methods: get status (for higher-level objects to check functional state; if busy, for example) and query object (for getting DATA; how many metwork sockets are open, for example), two meta methods: clone object (from the interpreter) and reproduce (hardware), 4 lateral methods (move data in or out), run object, ...
There are no SUPER calls -- all objects are subservient to super classes and are not allowed to pester their parents. Further, there is no data manipulation of internal variables or states, except by the object itself; i.e. all data is PRIVATE. However, children can pass up exceptions that couldn't be handled by themselves. If a parent can't handle (or doesn't), it must go to the programming environment, the operating system, or failing those, the hardware fails.
XXX REMOVE Each object should have a piece of canonical data returned from the object when it is used in an expression, like a variable. This should be affiliated with the object`s SWEAR contract. It could be the cursor position of a database object or properties of a window object, etc. (Python users: This is their REPR data, which differentiates itself from the STR data which might be output with the run method.)XXX
Meta-objects (containers) get 2 to 4 additional methods: the index operator[], containment test, count (How many objects are in the container?), and non_zero (is it empty?).
All objects should contain metadata to store: point_of_origin (an Internet address to get new versions), version, PayPal_ID.
???Object initialization can take any serial data stream (like reading a file), and whip it into the construct the data was designed for (a video, for example): VideoMP4("\marshalled\media\myvideo.mp4") will load and initialize the object. That construct can then be interacted with through the special five methods. >> might allow you to add frames to the video, for example (frameData >> myvideoobject), or maybe the object is a player and will queue up the item. Metaclasses take any other type and spit out another class.??? This was to make use of optimizations available at object creation, but may be irrelevant.
Object inheritance is for creating more sophisticated semantics. But start with basic semantic elements first.

Object compositing. Specializing your datatype (as the programmer) generalizes it towards the user who works in conceptual-space, not code-space, just like Unix did for the command-line utilities. To create this, programmers create super-objects: object mashups, allowing the hybridization and cross-fertilization of object traits into re-useable, higher-level applications that are also their own object. Unix SHOULD copy this behavior by allowing pipes into shell-scripts, forcing shell programmers to think architecturally in harmony with their host.
Every app is an object and every object is an app. Every object can be run (1/myObject) and do something interesting, otherwise what good is it? Containers (meta-objects) can pretty-print their contents. (Python: The method handles this and takes the object from the programmer`s perspective and flips it into the user`s perspective -- a little micro-application. This understanding between users and programmers clears up various ambiguities like Python's str() vs. repr(). Str() is for the user and repr() for the programmer.) Here is where you ascend to be the master of data. For example, invert your video object and a window appears playing the video. Do the same to a table of data, and a nice pretty-printed tabulation of the data might appear. Or maybe an object just outputs a text fortune cookie. In any case, let it do something interesting, so other user's will want to interact with your object.
The host environment should also have built-in meta-operators that make it easy to test and inspect objects: "&" (followed by the object name) for testing and validation, "<<" saves an object to your local environment, ">>" publishes it to the world at large, "@" for examining all the docs for the object.
Users shouldn't have to wonder about the purpose of foreign objects or objects within a complex object hierarchy. To this end, DocTests are the sugar you want with your objects. Languages with optional "DocStrings" are the best idea. This way you get documentation also--an essential part of the data ecosystem. Between the name of the object and it`s DocString you have everything you should need to know what the object does. See also TightCoupling.
Users also should be able to trust other objects. Specialized keywords (like implore (input contracts), swear (output contracts), and need/requires (pre-call output contracts and parameter contracts that negate the need for try..except warts in code)) can ensure that everything is acting as it should when you're not looking. A shared global purgatory can store objects whose behavior did not match their sworn contracts, so everyone on the network can know about it (and try to fix it). (Object creators who change these contracts must create a new object with a different name to show that the old contracts are not valid.)
Since files are a just a '''type of data''', you can create a whole shell and windowing OS with the above. You can set aside EMACS, you can have LanguageAsAnOS! Applications can be created and started by compositing objects. Your language and the OS are one with the application. The kernel still has to handle how to store all the data, but that's a different problem.
Boom, you're the w0/man. Now go find the GlassBeadGame at sourceforge (also Singularity at github) and help make it a reality.

Any bias towards the language in the foregoing of Python is due to the fact that it is the furthest along in providing the tools for a data ecosystem. So please overlook such bias as any language that offered similar ease would be equally chosen for the host environment.

So to clear up some long-standing confusion: a "class" is a "type" until it's instantiated into an "object". In some languages (like Python), a "type" is a "class", allowing metaclasses. Metatypes (aka metaclasses) are classes that take other classes and spit out another class. These classes have to be initialized to be used. Metaobjects are objects that hold other objects (aka containers). In some languages they are already initialized by special syntax, like "[]" symbols. This is an important new term to distinguish object relations in languages where "everything is an object".

If all this is a bit much for you, steer back to the OneTruePath. If it's not, get ready for the next Object Revolution!

If Objects are the right architecture for a data ecosystem and complex data architectures, then constraints are the right engineering. Asserts can be repurposed to accept object conditions and delegate to other objects to attempt to meet the constraint and fail if and when the object(s) in the condition

Also, the keyword "in" and concept of set membership is a generalizable construct transcends any data or application

membrane:

for -- to,
function - assign,
data in- dataout,
input in-print out.
math operations (the -1)

Add: functions remain separate, where by the input type is identical to output type.

Here endeth the lesson. Please return to your seats.

All rise:

Your data and programming environment should provide standard ways in which to inspect objects (outside the objects knowledge) and also get a handle, probably from the higher app, in which to connect to an inner objects data-in stream.

See also:

Gospel of Data Ecologies

OOP aphorisms:

If you can't describe your object in one clause, then you probably need to split it up into multiple objects.
Objects should set up common variables in the outer layer doctests so that inner layers can use them in doctests.
Make your object do something interesting (as a micro-app, like a String object can make an ascii string out of raw bytes). If it can't do that, either you've imagined it wrong, or you should move it up into another object.
Use GoodNaming. Separate words with UpperCase, and be as high-level descriptive as you can.
?Use inheritance or in-class inclusion? Cloning could clone all dependencies in your inherited class list.
If you change the class in a way that breaks your contracts, give it a new major version. But if your class is now going to be a different FUNCTION, rename the CLASS. You should have thought ahead.
In the biomimicry model of objects, "run" might be a meta-method for a higher-level ABC OR the data ecosystem itself. Also, news headlines might get bundled into a new object and stored as a memory struct.

Get ready for some real, mind-altering experience of how you relate to the data universe and how you can interact with the powers of the machine. Yeah, we know you've done double-pointer indirection and grokked the problems of non-tail recursion, but have you really understood the power of categorizing data and the object universe? How are you going to utilize >1MHz processing and >1Mb memories with your old models without buckling under the weight of your inadequate architectures? Microsoft, IBM, and DEC has a billion dollars to spend to upkeep their software, but do you? Probably not. No amount of engineering can solve the problem of scaling complex data. (It took philosophy to solve it, btw.) So, here's the skinny on wrapping your mind around any-size data of any complexity. It will still take about log₂ n human categorizations of your data, but this is eminently manageable. Beyond this, you don't need to master the problem domain yourself, like those poor saps trying to sell accounting or database software, because once you start the process, it only takes a high-school, nerd-level experience to make useable applications.

OOP is out-of-date. It had some confusion about whether "everything is an object" and the false peak of templating systems to re-use code in different type-contexts ("false peak" because most use of such different types is a semantic difference, so it makes no sense to conform syntactically), it has never reached it`s noble goals of re-useable code. Nothing against the great minds who put these ideas together though -- they were necessary waypoints to see further. Anyway, that is/was one of the goals of OOP -- not theoretical purity or saving code, although that it can achieve as well. This document creates a new level of understanding through the application of philosophy, namely epistemology and metaphysics, answering problems with object hierarchies to make a loosely-coupled, modular, uniform, fractal, set of objects which creates a complete, simple system -- a theory of everything for data, you could say.

Most programmers never got past Design Patterns (Booch, et alia), but this is a low bar just to ensure that your objects don't totally fail. We can do better than that. We can focus on syntactic solutions to semantic problems and map them 1-to-1, without creating a large, unwieldy system.

This page is to help sort out the confusion that you undoubtedly have, because the whole field is confused. Most programmers thought you should simulate real-word objects (Square is-a Shape) and while C++ originates with SIMULA, most programs are not simulations. Generally, objects do not simulate things in the real world. We are making a new, data landscape that needs new physics of interactions. A "Student" object is not simulating a student, it is a record of who that student is and what that student is doing and it interacts not with other students, like a simulation, but with the University, via classes, schedules, etc. The value of OOP in the age of the internet is going to be massive amounts of data processing (exabytes) into elegant ontologies of knowledge.

TL;DR or Zen version for those who don't want to read and cogitate, go here.

GOOP - LeFreq/Singularity GitHub Wiki

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️