The major concept of Paml is to design and implement a modeling language that strictly conforms SOVOP concepts.
OOP supports this approach, but seems OOP is not as good as we want. If someone practices OOP, he needs also a lot of patterns, idioms, approaches like SOLID, GoF, DDD, MDD, AOP – all these technics improve OOP to have practical value. OOP languages (with their abstractions such as encapsulation/inheritance/polymorphism) do not ensure those technics, only discipline and experience/knowledge of humans can probably provide a valuable result.
If we take, for example, Haskell, the result will definitely be a functional program. If we take C# or Java, the result can be anything, and even not object-oriented program at all. Modern trend to multi-paradigm languages like Scala is good, but Paml is designed to be "pure" object modeling language (at least on modeling level).
Paml strictly conforms to object modeling (may be in some naïve manner). At Paml level, a modeling system is defined exactly as collaborating objects. In this sense Paml is similar and strict as FP languages are strict by functions.
But at implementation level, object models in Paml are not enough. Paml provides the ability to define implementation details in GPL like C# (which is Turing complete) by transformations/productions mechanism. So, Paml is actually a modeling language with ability to produce source code. Paml is not a replacement for GPL, but a tool to ensure SOVOP modeling concepts using GPL.
Generated source code in GPL should be readable?
Actually Paml is a DSL for object modeling; it composes several existing concepts, technics and practices, and provides them via its syntax/semantics.
Axioms of OOP are replaced by SOVOP ones. Abstract term "object" has more concrete sense. Values exist by definition and they are not subjects/objects. Object state and object behavior (messages) are explicit but separated by definition.
In modern practice, immutable objects are very popular as a way to make programs more robust, error-free and maintainable. But look at this from different point of view: objects have a state by definition, and the state is a feature of object modeling. Moreover, mutable state is required in object modeling as an objective property of computing system. It seems that it’s impossible to implement a computing system with practical value using only immutable objects. And the same matter, it’s impossible to implement a system using only pure functions in FP languages (for example, they violate the property of determinism: depending only on parameters). As result, immutable objects seem misnamed, they are not objects at all – they are values.
Subjects/objects communicate via message exchange. High level abstraction for a message is a routine. A routine defines high level statements in the Template Method pattern style. For manipulating data, declarative LINQ style seems can be used.
Transformations and productions – this is a feature that produces the output code on GPL like C#. Transformations concepts are based on AOP and MDD concepts, but in some generalized way. Paml separates "what" and "how" in wider sense. "What" – this is models (subjects/objects/values/routines) and "how" – this is anything else. In fact, "how" seems like aspects/advices in AOP, but it also can be much more: creating an object, logging, audit, transactions, communicating details like protocols, validating pre- and post- conditions, test covering etc. It probably seems that all technical matter is "how".
Transformations intercept messages (but actually routines) and can change them into particular output code. The approach is used in COM+, and seems it could be used in object collaboration in general way.
Transformations select models (subjects/objects/values/routines) and change them according transforming semantics. Paml is a metalanguage in this sense, operating on high level models and producing source code. Syntax style could be like jQuery selects nodes in DOM, but Paml uses this to operate on objects and messages (something like selecting from AST?).
Productions are a kind of transformation that produces new elements, required to implement a system and that are derived from base models (subjects/objects/values). Elements in the generated source code (classes, methods, etc) are not written but produced, and can be tracked where they come from.
Unit testing is a required technic in modern software development discipline. Paml provides the ability to define unit tests as close to testing elements as possible. In fact, testability is a property of some code element like an object or a message, so unit testing can be treated as a transformation from just "element" to "testable element", assigning to the element any number of unit tests.
For transformations, dedicated posts will be provided, because transformations seem is a powerful way to produce source code from models (idea from MDD). Also they seem an alternative way for polymorphism instead of inheritance/virtual methods, though these ideas are not new in general.
Write a comment