Problems of the OSNO: Incomplete object paradigm and premature typing
In the previous article it was about the problem of the OSNP in general, in this article I would like to develop this topic and to show more specifically the problems of the OOJP.
The main ideas are
The ODLs have two key problems: an inferior object paradigm and premature typing. The incomplete object paradigm does not define the concept of untyped object composition (the composition is an essential element of any paradigm). Premature typing limits the semantics of abstract concepts (semantic abstractions).
The incomplete objective paradigm
The objective paradigm does not explicitly define the basic mechanisms. Any paradigm should define:
- defines the paradigm thinking style and is the basic element of modeling.
Composition of primitives
- allows to describe (simulate) systems of arbitrary complexity. The composition itself must also be a primitive.
The aggregating ratio is
- An abstract mechanism that links primitives into compositions. Exactly the same mechanism manifests a primitive in external interaction.
The global state is
- where (but not how!) The abstract (observed) state of the system will be localized. This property is not just a paradigm, but a consequence of the computing architecture. The result of execution of any model can be detected only by changing the state in the most general sense.
the paradigm is defined in the untyped form
. To use the paradigm (not to be confused with the use of the JAI based on this paradigm), typing is not needed. The paradigm should only determine how and on what mechanisms the model is built (ie one or more compositions).
Even more importantly, the composition, not the primitive, is a "brick" in modeling due to the complexity of the simulated systems.
The compositions are pure semantic abstractions of
, without type binding or any other "resources". Semantic abstraction is a concept given only by one's own name, and a name in an arbitrary form, a word or a phrase.
For example, the functional paradigm completely satisfies these properties (the same can be shown for the procedural /imperative paradigm):
Primitive of abstraction: function is the mapping of some input to some output.
Functional composition: a chain of functions (mappings).
Aggregating relation: the output of one function is fed to the input of the other. Those. this is a link in the composition, and the call of the function as such.
Global state: arguments of functions.
In OOP and the current definitions of the object paradigm, the object composition is at best implied, at worst there is none at all. The so-called
postulates of OOP (abstraction /encapsulation /inheritance /polymorphism)
- this is an abstract set of concepts, the latter two generally refer to typing and to the object paradigm have nothing to do.
Everything is an object. Objects interact with each other.
- here the object composition is at least implied, and somehow it can be logically derived.
Of course, in the SNRP it is technically possible to see the compositions in one form or another, but
object composition should be the basic and basic mechanism of the SNFS, and not an optional and secondary
How should the object paradigm (similar to the functional paradigm) look like:
Primitive abstraction: object is an agent that supports some protocol of interaction. The protocol implies rules and semantics of interaction for both parties.
Object composition: a graph of objects that support each other's protocols. The graph itself is an object with its own protocol.
Aggregating relation: support of the object protocol (ie understanding the protocol and following it). The ability to support each other's protocol links objects to a composition, as well as external interaction with a specific object is possible only if its protocol is supported.
Global state: the internal state of the object.
A distinctive feature of the objective paradigm is that
object, in contrast to the function and procedure, is not purely transformative (ie, state-changing) primitive
. Because the global state is distributed by objects (in the DOS it is encapsulation), the object's protocol becomes a way of changing the state. This should be reflected at the level of the object paradigm.
For this, the object paradigm can use any paradigm with a transforming primitive, a proper functional and /or procedural paradigm for object protocols. Both paradigms are used in the same abstract, untyped form. If the object protocol is based on a functional paradigm, we get a non-manipulative object, if on the procedural one it's mutable.
Typification (type system) is ultimately necessary for a single purpose:
formal verification of the correctness of
programs. The rules are given through the grammar of the JA, the grammar-based translator conducts the actual verification.
The premature typing is that OOPs (class-oriented) make a strong emphasis on the use of types, on the interpretation of classes as types. The first thing that catches your eye (both in practice when using the OOJP, and in textbooks /books when describing the OSNO) is a system of OOJP types, although in theory there should be an object paradigm with its composition and semantic abstractions. Reference types and value types, subtyping polymorphism, inheritance, Lisp substitution principle, method overloading, generics, abstract data types, functional type and PWD as elements of functional programming, type deduction, type casting, abstract classes and interfaces - all these concepts are the consequence of typing.
On the one hand, typing is inevitable, because only the correct programs can be executed. But on the other hand, the appearance of typing introduces restrictions on the semantics of abstractions. The idea is to postpone the typing process as late as possible. In other words,
formal verification of correctness should be made only after the object composition
is determined. . Ideally, typing should be pluggable, its place somewhere before the compilation stage, and at the compilation stage, verification is actually performed.
If you look at typing more widely, then
premature typing in the DOS appears also in a fixed interpretation of abstract mechanisms of the object paradigm in the form of specific types of implementation
. A case in point is that the object protocol (the same contract) is rigidly implemented as methods with fixed structure and behavior (parameters, return value) as one of the possible types of implementations of the object protocol. The reason for adding async /wait modifiers in C # - apparently it became clear that the hard (synchronous) connection between the method call and the return value does not correspond to practical tasks. In fact, this correction of the consequences of premature typing. Again, ideally, a particular type of protocol implementation must be plug-in, with a particular implementation of any mechanism.
The idea of plug-in typing seems to me in the form of several stages (it's not some kind of waterfall process of software development, all the stages occur when writing code without leaving the IDE).
An object model (one /several untyped object compositions) that contains only semantic abstractions is described. Objects, their protocols, compositions of objects - all are informally described in the form of semantic abstractions. At this stage, the meaning of the object model follows from the concepts themselves.
occurs. attribution, i.e. definition (binding) of untyped attributes for semantic abstractions
. As a result, we get attributed semantic abstractions. Attributes are not data fields, properties, etc. from OOP /OOPS, attributes define
the semantic structure of
concepts. At the stage of attribution there is no concept of state at all.
The next stage is
abstract (untyped) implementation of the protocols of objects
(speaking traditionally - the implementation of methods). For object protocols, the implementation paradigm with transforming primitives (functional and /or procedural) is chosen. At this stage, attributes are already available, but they (like abstract functions and /or procedures) are still semantic abstractions. The use of transforming paradigms at this stage implies an abstract state of objects (once there is something to transform), and the structure of this state just follows from the attributes of objects.
a concrete (typified) implementation of
- it is here that the types are bound to objects and their attributes, as well as parameters /arguments in object protocols. Abstract procedures /functions of the abstract implementation of object protocols are concretized to traditional constructions such as class methods.
Separately, I note that type binding occurs through the injection of expressions, rather than specifying a type name. In other words, the type is derived from the type of the expression, which guarantees explicit initialization.
After the stage of a concrete implementation, all concepts are typed, and you can conduct formal verification (as part of the translation).
The identified problems, in my opinion, are the reason that the DOS are fundamentally contradictory. Not surprisingly, the OOPs and OOPs in their current form will always be the object of criticism.
There is also a third problem, but it concerns not only the OOJP, but also other languages: it is a syntax based on a text grammar. Currently, the support for text grammars in the IDE is so developed that the question arises: why do we need a textual representation of the code? IDEs manipulate entire structural blocks such as methods or expressions that the text as such degenerates. Do you compare versions in version control systems like text? But this is only a matter of implementing support in the IDE.
The syntax based on the text grammar limits the meta-capabilities for the same reason that the meta-level requires additional support from the IDE, and there is no particular sense in setting them as text. Those. Meta-features are implemented only at the IDE level. In fact, the IDE is a grammar.
Therefore, the global idea is to develop an object-oriented language (ie IDE) on the basis of a distinct object paradigm, without text grammar and with advanced meta-capabilities for transforming object compositions into readable code.
It may be interesting
Situs QQ Online
Situs QQ Online