User:Average/Gospel of Object Oriented Programming

OOP has gotten very confused. Besides reaching a plateau of "everything is an object" which it doesn't seem to know how to get itself beyond, it has never reached even it`s noble goals of re-useable code. That had been one of the goals of OOP, not theoretical purity.

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), but most programs are not simulations. No, the real value of OOP in the age of the internet is going to be massive amounts of data processing (exabytes) into elegant ontologies of knowledge. In other words: data itself is the gold we're looking for -- the fundamental value-unit.

Please stand.

• First, you must realize the ultimate nature of data: that (betwixt random numbers and NULL), it relates to something, it does not exist in isolation to everything else. It has it's own nature.
• Then, you shall realize that every datum relates to all other data: you just haven't discovered it`s place in the ontology. Your file system has been acting as a buffer for your ignorance and passivity. Your applications, pimping up your data.
• And finally, that the ultimate machine for such an ontology is a unified, 3-dimensional visualization model where the language is the OS. But then, you ask.... how?

---

...and begin:

1. 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 or structs (tables for you DB users). And without a label, don't call it an "object".
2. The object domain (or DataEcosystem) is a nascent field, but there should be noted only two kinds of object interactions: users-of-objects and makers-of-objects. The former I'll term users (sometimes: higher-level "applications") and the latter programmers. Programmers are also users, but users are not always programmers. Applications never are -- in this context, these are sometimes called mashups. The point is that there is no canonical way to refer to a object syntactically (uppercase vs. lowercase, e.g.), as there will always be more than one kind of relationship to it.
3. It is a grave sin to attempt great ontologies of objects starting with Abstract Base Classes and building towards specialization. This is backwards (cf. single-table databases). Start with concrete base classes, like <int>, 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. Just as a raindrop is said to form around an impurity in the air, form your objects around the machine types. Container objects (objects holding objects) are then meta-objects where ABCs are appropriate. Here's a guided meditation.
4. 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. Just as there are only 26 letters to handle the entire corpus of English text, there are only five functions needed to handle every object need: query-object (?), clone-object (%), receive (>>), send (<<), and run (1/). These operators are meant to scale all the way up so that, for example, 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.
5. 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.
6. 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.
7. Every object should be able to be run (1/myObject) and do something interesting, except for containers (meta-objects), otherwise what good is it? The __invert__ 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.
8. 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.
9. 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.
10. Users also should be able to trust other objects. Specialized keywords (like implore (input contracts) and swear (output contracts)) 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).
11. 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.
12. Boom, you're the w0/man. Now go find the GlassBeadGame at sourceforge 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 come languages (like Python), a "type" is a "class". Metatypes (aka metaclasses) are classes that take other classes and spit out another classes. 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!

Here endeth the lesson. Please return to your seats.