Alternative OOP: SOVOP and Paml

The idea is to design and develop alternative object programming approach. 

Axioms of OOP: 

1. Everything is an object. 
   
2. An object has its state. 
   
3. The only way to read/change the state of an object is sending messages to the object. 

There are other three OOP principles: encapsulation, inheritance and polymorphism. But it seems they are not exact OOP concepts, but one of possible way of abstractions based on OOP axioms (though this way of abstractions is provided in most OOP languages). 

There are a lot of critics of OOP, so the idea is to design and develop alternative OOP concepts, and basing on it develop a modeling language that will strictly adhere the new concepts. 

The alternative concept is named SOVOP that stands for Subject/Object/Value Oriented Programming. The concept is not an invention; it uses elements of OOP, AOP, DDD. 

1. Not everything is an object: there are subjects, objects and values. 
   • Subjects define a topology of a modeling system. 
     
   • Objects implement some functionality. 
     
   • Values are pure data. 
     
2. Subjects and objects have their state. 
   • State is a value. 
     
3. The only way to read/change the state of subjects/objects is sending messages to them. 
   
   • Details of implementation of a system are intercepting the messages. 
     
4. Modeling purpose is to define a set of communicating subjects that are exchanging messages. 
   
   • Messages are implemented using other subjects/objects, generally named collaborators. 
     

Basing on the SOVOP axioms, Pallada Modeling Language (Paml) is introduced. The reasons for Paml concepts are the following. 

Paml is a DSL for developers who model systems as communicating objects. For now, seems all OOP concepts, patterns, idioms are expressed in source code of general-purpose languages. 

Paml is a textual modeling language that strictly requires SOVOP. In this sense it seems like FP languages with their strict term of a function. 

Paml is a modeling language. It probably is not Turing complete, but this is even not required. Paml provides pure high-level abstraction models (subjects/objects/values), so they are separated from implementation details. As result, it’s possible to share models as knowledge. 

Paml will generate source code on general-purpose languages. So Paml could be seen as a way to write programs indirectly, via models and their transformations. For prototyping purpose the output language is C#.  

Paml treats literally communicating subjects/objects. So the primary terms are subjects/objects, not classes or anything derived from objects. Of course, Paml will provide polymorphic behavior but this is provided by transformation mechanism from models (subjects/objects/values with messages).

Paml has declarative and, probably, functional styles. The key and the only way to implement a system is interception of messages of subjects/objects. 

The actual Paml syntax/semantics design will be described in future posts. 

I'm not sure what is the idea: one step forward or two steps back in our software industry, but anyway I want to try to get know.