Rules for OOP - LeFreq/Singularity GitHub Wiki

Following the ethos of the Rule of Four, here are the 4 rules + and - 1 for a perfect object ecosystem:

1. An object must be discrete encapsulations of data + code, set off with a NAME. Generally, if it's not data and code, then make it a function or a struct.
2. Each object has two primary customers or use-cases: users and programmers. Users rely on being able to find documentation for the object and test it for compliance. Programmers are the squirrely bunch who want to get into the fine grit. These are the ones who open up objects.
3. No more domain-specific languages. There cannot be an infinite number of objects kinds, so determine the primary objects and make everything grow from there. An object should conform to a consistent, predictably-available methods for interaction. A universal language should be conformed to consisting of <<, >>, ? (query-state), and % (clone-object) operators.
4. An object should be useful enough to be a little mini-application, much like Unix command-line tools, otherwise what good is it? This means it must be runnable.
5. All objects should be uniquely named within the ecosystem and doctests which describe what the object is meant to do and show what to expect with each method. Metadata for each object should hold the paypal address for the programmer, a website to find pristine or updated objects, etc. should be stored with each object to establish trust metrics between different programmers.
6. Contracts should exist such that a program can specify a needs request, much like an RFC, so that the ecosystem can try to provide that utility. Similarly, all objects may contain within them a publishes statement that tells the ecosystem what the object publishes to the system. These tests(?) may be eliminated once trust or reliability is established.XXX This might be swear and implore statements. This forces objects to state what data types are accepted (into the in and out methods) so there are no uncaught exceptions. The implore can take a more primitive object type (like an integer) and co-erce it into a more sophiticated type to make it more useful.

Such a system will scale to endless limits as well as provide service downwards to any code over about 1000LOCs. Former ideas of implore and promise are suggested to be reactive modes of programming, while the needs and requires are proactive modes for programming. However, these are reactive so that they can be more than passive documentation. An implore function can co-oerce objects into a parent's desired type. A function similar to Purgatory with the vigil system could hold objects which have broken their contracts and need evaluated and/or repaired before returning to the ecosystem.

---

Objects start as primitive types and grow towards more sophisticated inherited objects. This is a reversal of the biomimicry of the soul (actually there are two directions of growth, one of which grows towards simplification which si where this project comes from) where cells get purer and purer removing everything unnecessary.