EOLANG and $\varphi$-calculus

Abstract.

Object-oriented programming (OOP) is one of the most popular paradigms used for building software systems. However, despite its industrial and academic popularity, OOP is still missing a formal apparatus similar to $\lambda$-calculus, which functional programming is based on. There were a number of attempts to formalize OOP, but none of them managed to cover all the features available in modern OO programming languages, such as C++ or Java. We have made yet another attempt and created $\varphi$-calculus. We also created EOLANG (also called EO), an experimental programming language based on $\varphi$-calculus.

1. Introduction

It is difficult to define what exactly is OOP, as “the term has been used to mean different things,” according to Stefik and Bobrow (1985). Madsen and Møller-Pedersen (1988) claimed that “there are as many definitions of OOP as there papers and books on the topic.” Armstrong (2006) made a noticeable observation: “When reviewing the body of work on OO development, most authors simply suggest a set of concepts that characterize OO, and move on with their research or discussion. Thus, they are either taking for granted that the concepts are known or implicitly acknowledging that a universal set of concepts does not exist.”

1.1. Lack of Formal Model

The term OOP was coined by Kay (1997) in 1966 and since then was never introduced formally (Kay, 1986). Back in 1982, Rentsch (1982) predicted: “Everyone will be in a favor of OOP. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is.”

There is a fundamental problem in OOP—the lack of a rigorous formal model, as was recapped by Eden and Hirshfeld (2001): “Unfortunately, architectural formalisms have largely ignored the OO idiosyncrasies. Few works recognized the elementary building blocks of design and architecture patterns. As a result of this oversight, any attempt to use formalisms for the specification of OO architectures is destined to neglect key regularities in their organization.”

There is no uniformity or an agreement on the set of features and mechanisms that belong in an OO language as “the paradigm itself is far too general,” as was concluded by Nierstrasz (1989) in his survey.

OO and semi-OO programming languages treat OOP differently and have variety of different features to follow the concept of object-orientedness. For example, Java has classes and types (interfaces) but doesn’t have multiple inheritance (Alpern et al., 2001), C++ has multiple inheritance but doesn’t directly support mixins (Burton and Sekerinski, 2014), Ruby and PHP don’t have generics and types, but have traits (Bi and Oliveira, 2018), JavaScript doesn’t have classes, but has prototypes (Richards et al., 2010), and so on.

It was noted by Danforth and Tomlinson (1988) that object-oriented programming, like functional programming or logic programming, incorporates a metaphor in which computation is viewed in terms divorced from the details of actual computation. However, in the case of OOP, this metaphor is rarely introduced with the mathematical precision available to the functional or logic programming models. Rather, OOP is generally expressed in philosophical terms, resulting in a natural proliferation of opinions concerning exactly what OOP really is.

1.2. Complaints of Programmers

Although the history of OOP goes back for more than 50 years to the development of Simula (Dahl and Nygaard, 1966), OOP is under heavy criticism since the beginning to nowadays, mostly for its inability to solve the problem of software complexity.

According to Graham (2004), “somehow the idea of reusability got attached to OOP in the 1980s, and no amount of evidence to the contrary seems to be able to shake it free,” while “OOP offers a sustainable way to write spaghetti code.” West (2004) argues that the contemporary mainstream understanding of objects (which is not behavioral) is “but a pale shadow of the original idea” and “anti-ethical to the original intent.” Gosling and McGilton (1995) notes that “unfortunately, ‘object oriented’ remains misunderstood and over-marketed as the silver bullet that will solve all our software ills.”

1.3. High Complexity

Nierstrasz (2010) said that “OOP is about taming complexity through modeling, but we have not mastered this yet.” Readability and complexity issues of OO code remain unsolved till today. Shelly (2015) claimed that “Reading an OO code you can’t see the big picture and it is often impossible to review all the small functions that call the one function that you modified.” Khanam (2018) in a like manner affirmed: “Object oriented programming promotes ease in designing reusable software but the long coded methods makes it unreadable and enhances the complexity of the methods.”

The complexity of OO software is higher than the industry would expect, taking into account the amount of efforts invested into the development of OO languages. As was concluded by Bosch (1997), “OO frameworks have number of problems that complicate development, usage, composition and maintenance of software.”

For example, the infamous legacy code has its additional overhead associated with OO languages—inheritance mechanism, which “allows you to write less code at the cost of less readability,” as explained by Carter (1997). It is not infrequently when “inheritance is overused and misused,” which leads to “increased complexity of the code and its maintenance,” as noted by Bernstein (2016).

The lack of formalism encouraged OOP language creators to invent and implement language features, often known as “syntax sugar,” which are convenient for some of them in some special cases but jeopardize the consistency of design when being used too often and by less mature programmers. The most obvious outcome of design inconsistencies is high complexity due to low readability, which negatively affects the quality and leads to functionality defects.

1.4. Solution Proposed

EO was created in order to eliminate the problem of complexity of OOP code, providing 1) a formal object calculus and 2) a programming language with a reduced set of features. The proposed $\varphi$-calculus represents an object model through data and objects, while operations with them are possible through formation, application, and decoration. The calculus introduces a formal apparatus for manipulations with objects.

EO, the proposed programming language, fully implements all elements of the calculus and enables implementation of an object model on any computational platform. Being an OO programming language, EO enables four key principles of OOP: abstraction, inheritance, polymorphism, and encapsulation.

The following four principles stay behind the apparatus we introduce:

• An object is a collection of attributes, which are uniquely named bindings to objects. An object is an atom if its implementation is provided by the runtime.

• An object is abstract if at least one of its attributes is void—isn’t attached to any object. An object is closed otherwise. Formation is the process of creating a objects. Application is the process of making a copy of existing object, specifying some or all of its void attributes with objects known as arguments. Application may lead to the creation of a closed object, or an abstract one, if not all void attributes are specified with arguments.

• An object may decorate another object by binding it to the $\varphi$ attribute of itself. A decorator has its own attributes and attached attributes of its decoratee.

• A special attribute $\Delta$ may be attached to data, which is a computation platform dependable entity not decomposable any further. Dataization is a process of retrieving data from an object, by taking what the $\Delta$ attribute is attached to. The dataization of an object at the highest level of composition leads to the execution of a program.

The rest of the paper is dedicated to the discussion of the syntax of the language that we created based on the calculus, the calculus itself, its semantics, and pragmatics. In order to make it easier to understand, we start the discussion with the syntax of the language, while the calculus is derived from it. Then, we discuss the key features of EO and the differences between it and other programming languages. We also discuss how the absence of traditional OOP features, such as mutability or inheritance, affect the complexity of code. At the end of the paper we overview the work done by others in the area of formalization of OOP.

2. Syntax

The entire syntax of EO language in BNF is available on the first page of the objectionary/eo Github repository. Similar to Python (Lutz, 2013), indentation in EO is part of the syntax: the scope of a code block is determined by its horizontal position in relation to other blocks, which is also known as “off-side rule” (Landin, 1966).

There are no keywords in EO but only a few special symbols denoting grammar constructs: for the attributes naming, for the dot notation, for the specification of parameters of formations, for scope limitations, for turning objects into constants, for naming arguments, (double quotes) for string literals, for the decoratee, (apostroph) for explicit copying, for object identity, for referring to the parent object, for referring to the home object, and for referring to the current object. Attributes, which are the only identifiers that exist in EO, may have any Unicode symbols in their names, as long as they start with a small English letter and don’t contain spaces, line breaks, or special symbols mentioned above: and are valid identifiers. Identifiers are case-sentitive: and are two different identifiers. Java-notation is used for numbers and strings.

2.1. Identity, State, and Behavior

According to Booch et al. (2007), an object in OOP has state, behavior, and identity: “The state of an object encompasses all of the properties of the object plus the current values of each of these properties. Behavior is how an object acts and reacts, in terms of its state changes and message passing. Identity is that property of an object which distinguishes it from all other objects.” The syntax of EO makes a difference between these three categories.

This is a formation of a new object , which has a single identity attribute :

To make another object with a specific ISBN, the has to be copied, with the data as an argument:

Here, is a new object created. Its only attribute is accessible as .

A similar abstract object, but with two new state attributes, would look like:

⬇

1  "Object Thinking" > title

2  memory 0 > price 

The attribute is a constant, while the represents a mutable chunk of bytes in computing memory. They both are accessible similar to the , via and . It is legal to access them in the abstract object, since they are attached to objects. However, accessing will lead to an error, since the attribute is void in the abstract object .

A behavior may be added to an object with a new inner abstract object :

⬇

1  "Object Thinking" > title

2  memory 0 > price

3  [p] > set-price

4    ^.price.write p > @ 

The price of the book may be changed with this one-liner:

2.2. Indentation

This is an example of an abstract object , where spaces are replaced with the “␣” symbol in order to demonstrate the importance of their presence in specific quantity (for example, there has to be exactly one space after the closing square bracket at the second line and the symbol, while two spaces will break the syntax):

⬇

4[dx␣dy]␣>␣vector␣

5␣␣sqrt.␣>␣length␣

6␣␣␣␣plus.

7␣␣␣␣␣␣dx.times␣dx

8␣␣␣␣␣␣dy.timex␣dy␣␣

The code at the line no. LABEL:ln:comment is a comment. Two void attributes and are listed in square brackets at the line no. 4. The name of the object goes after the symbol. The code at the line no. 5 defines an attached attribute . Anywhere when an object has to get a name, the symbol can be added after the object.

The declaration of the attribute at the lines 5–8 can be written in one line, using dot notation:

An inverse dot notation is used in order to simplify the syntax. The identifier that goes after the dot is written first, the dot follows, and the next line contains the part that is supposed to stay before the dot. It is also possible to rewrite this expression in multiple lines without the usage of inverse notation, but it will look less readable:

⬇

8.plus

9  dy.timex dy 

10.sqrt > length 

Here, the line no. LABEL:ln:dx-pow is the application of the object with a new argument . Then, the next line is the object taken from the object created at the first line, using the dot notation. Then, the line no. 9 is the argument passed to the object . The code at the line no. 10 takes the object from the object constructed at the previous line, and gives it the name .

Indentation is used for two purposes: either to define attributes of an abstract object or to specify arguments for object application, also known as making a copy. A definition of an abstract object starts with a list of void attributes in square brackets on one line, followed by a list of attached attributes each in its own line. For example, this is an abstract anonymous object (it doesn’t have a name) with one void attribute and two attached attributes and :

⬇

2  x.plus 1 > succ

3  x.minus 1 > prev

The arguments of and are provided in a horizontal mode, without the use of indentation. It is possible to rewrite this code in a vertical mode, where indentation will be required:

⬇

10  x.plus > succ

11    1

12  x.minus > prev

13    1 

This abstract object can also be written in a horizontal mode, because it is anonymous:

2.3. EO to XML

Due to the nesting nature of EO, its program can be transformed to an XML document. The abstract object would produce this XML tree of elements and attributes:

⬇

13  <o name="dx"/>

14  <o name="dy"/>

15  <o name="length" base=".sqrt">

16    <o base=".plus">

17      <o base=".times">

18        <o base="dx"/>

19        <o base="dx"/>

20      </o>

21      <o base=".times">

22        <o base="dy"/>

23        <o base="dy"/>

24      </o>

25    </o>

26  </o>

27</o>

Each object is represented by an XML element with a few optional attributes, such as and . Each attribute is either a named reference to an object (if the attribute is attached, such as ), or a name without a reference (if it is void, such as and ).

2.4. Data Objects and Tuples

There are a few abstract objects which can’t be directly copied, such as and . They are created by the compiler when it meets a special syntax for data, for example:

⬇

3  r.times 3.14 > circumference

This syntax would be translated to XMIR (XML based data format):

⬇

27  <o name="r"/>

28  <o base=".times" name="circumference">

29    <o base="r"/>  

30    <o base="float">

31      <o base="bytes">40-09-1E-B8-51-EB-85-1F</o>

32    </o>

33  </o>

34</o> 

Each object, if it is not a formation, has a “base” attribute in XML, which contains that name of a formation to be copied. The examples of some possible data objects are in Table 1.

Table 1. The syntax of all data with examples. The “Size” column denotes the number of bytes in the attribute. UTF-8 is the encoding used in object.

Data	Example	Size
		4
		16
	or	2
	, , or	8
	or	8
	or	1

The syntax of all data with examples. The “Size” column denotes the number of bytes in the attribute. UTF-8 is the encoding used in object.

Table 1. The syntax of all data with examples. The “Size” column denotes the number of bytes in the attribute. UTF-8 is the encoding used in object.

The is yet another data, which can’t be copied directly. There is a special syntax for making tuples, which looks similar to object copying:

⬇

3* > a 

4  (* "a")

5  TRUE 

6* > b 

The code at the line no. LABEL:ln:tuple-1 makes a tuple of three elements: two strings and one float. The code at the lines 3–5 makes a tuple named with another tuple as its first element and as the second item. The code at the line no. 6 is an empty tuple with the name .

2.5. Scope Brackets

Brackets can be used to group object arguments in horizontal mode:

The is a copy of the abstract object with two arguments and . This object is itself the first argument of the copy of the object . Its second argument is . Without brackets the syntax would read differently:

This expression denotes a copy of with four arguments.

2.6. Inner Objects

An abstract object may have other abstract objects as its attributes, for example:

⬇

34[x y] > point

35  [to] > distance

36    length. > len 

37      vector

38        to.x.minus (^.x)

39        to.y.minus (^.y)

The object has two void attributes and and the attribute , which is attached to an abstract object with one void attribute and one attached attribute . The inner abstract object may only be copied with a reference to its parent object , via a special attribute denoted by the symbol:

⬇

6  point

7    5:x

8    -3:y

9  point:to

10    13:x

11    3.9:y

The parent object is , while the object is the argument for the void attribute of the object . Suffixes , , and are optional and may be used to denote the exact name of the void attribute to be attached to the provided argument.

2.7. Decorators

An object may extend another object by decorating it:

⬇

39  center > @ 

40  [p] > is-inside

41    lte. > @

42      ^.@.distance $.p 

43      ^.radius 

The object has a special attribute at the line no. 39, which denotes the decoratee: an object to be extended, also referred to as “component” by Gamma et al. (1994).

The decorator has the same attributes as its decoratee , but also its own attribute . The attribute may be used the same way as other attributes, including in dot notation, as it is done at the line no. 42. However, this line may be re-written in a more compact way, omitting the explicit reference to the attribute, because all attributes of the are present in the ; and omitting the reference to because the default scope of visibility of is the object :

The inner object also has the attribute: it decorates the object (stands for “less than equal”). The expression at the line no. 42 means: take the parent object of , take the attribute from it, then take the inner object from there, and then make a copy of it with the attribute taken from the current object (denoted by the symbol).

The object may be used like this, to understand whether the $(0,0)$ point is inside the circle at $(-3,9)$ with the radius $40$:

⬇

43c.is-inside (point 0 0) > i

Here, will be a copy of behaving like because decorates .

It is also possible to make decoratee void, similar to other void attributes, specifying it in the list of void attributes in square brackets.

2.8. Anonymous Formations

A formation may be used as an argument of another object while making a copy of it, for example:

⬇

11  *

12    [f]

13      f.is-dir > @

Here the object is copied with a single argument: the one-item tuple, which is a formation with a single void attribute . The will use this formation, which doesn’t have a name, in order to filter out files while traversing the tree of directories. It will make a copy of the formation and then treat it as a boolean value in order to make a decision about each file.

The syntax may be simplified and the formation may be inlined (the tuple is also inlined):

⬇

43  * ([f] (f.is-dir > @))

An anonymous formation may have multiple attributes:

This object has two attributes and , and doesn’t have a name.

The parent of each copy of the abstract object will be set by the object and will point to the object itself.

2.9. Constants

EO is a declarative language with lazy evaluations. This means that this code would read the input stream two times:

⬇

43  stdout > say

44    sprintf

45      "The length of %s is %d"

46      stdin.next-line > x!

47      x.length

The object will go to the two times. First time, in order to use it as a substitute for and the second time for . There will be two round-trips to the standard input stream, which obviously is not correct. The exclamation mark at the solves the problem, making the object by the name a constant. This means that all attributes of are cached. Important to notice that the cache is not deep: the attributes of attributes are not cached.

Here, is an attribute of the object , even though it is not defined as explicitly as . Anywhere a new name shows up after the symbol, it is a declaration of a new attribute in the nearest object abstraction.

2.10. Explicit Shallow Copies

There may be a need to make a copy of an object without giving any parameters to it. This may be done with an apostrophe suffix:

⬇

13p 3 5 > p1

Here, two objects will be created, and , where the former is an abstract one, a copy of , while the later is a closed one with two parameters specified. The apostrophe suffix may be used anywhere after the name of an object, for example:

⬇

47  point’ 3 a’

Making a copy of will not lead to making a copy of , which is encapsulated by .

2.11. Object Identity

Each object has a special attribute , which is an integer refering to a unique identifier of an object in the entire runtime scope of a program. All of the following expressions are true:

⬇

1342.<.eq (42.<)

14point.<.eq (point.<)

All of the following expressions are false:

⬇

47(2.plus 2).<.eq (4.<)

48(point 3 5).<.eq ((point 3 5).<)

49(* 1 2).<.eq ((* 1 2).<)

2.12. Metas and License

A program may have a comment at the beginning of the file, which is called a license. The license may be followed by an optional list of meta statements, which are passed to the compiler as is. The meaning of them depends on the compiler and may vary between target platforms. This program instructs the compiler to put all objects from the file into the package and helps it resolve the name , which is external to the file:

⬇

14# All rights reserved.

15# The license is MIT

16

17+package org.example

18+alias org.eolang.io.stdout

19

20[args] > app

21  stdout > @

22    "Hello, world!\n"

2.13. Atoms

Some objects in EO programs may need to be platform specific and can’t be composed from other existing objects—they are called atoms. For example, the object uses the object , which is an atom. Its implementation would be provided by the runtime. This is how the object may be defined:

⬇

49+rt ruby eolang:0.1.0

50

51[text] > stdout /bool 

The suffix informs the compiler that this object must not be compiled from EO to the target language. The object with this suffix already exists in the target language and most probably could be found in the library specified by the meta. The exact library to import has to be selected by the compiler. In the example above, there are two libraries specified: for JVM and for Ruby.

The part after the is the name of object, which decorates. The name may be replaced by a question mark, if uncertain about the object being decorated.

Atoms in EO are similar to “native” methods in Java and “extern” methods in C#: this mechanism is also known as foreign function interface (FFI).

2.14. Home Object

An instance of an abstact object may need to have access to the object where the abstract was defined, for example this is how object is implemented in Objectionary:

⬇

22  [f] > mapi /list 

23  [f] > map

24    ^.mapi > @

25      [x i] 

26        &.f x > @

The object at the line no. 22 is an atom: it iterates through list of items and makes a copy of the provided two-arguments abstract object applying the next item to it and the index in the tuple (that is why the name with the “i” suffix).

The object does exactly the same, but doesn’t provide the index of each element to the inner abstract object. The anonymous inner abstract object at the line no. 25 has to get access to the attribute of . However, won’t work, because the parent of it is a copy of , and the parent of is the object . Thus, there is no way to get access to using parent attributes.

The home attribute helps here. Once an abstract object at the line no. 25 is created, its home attribute is set to the abstract object at the line no. LABEL:ln:list-parent. Its parent attribute is also set to the object , but is later changed by the atom when a copy of it is being made. However, the home attribute remains the same.

3. Calculus

The proposed $\varphi$-calculus is based on set theory (Jech, 2013) and lambda calculus, representing objects as sets of pairs and their internals as $\lambda$-terms. The rest of the section contains formal definitions of data, objects, attributes, formation, application, decoration, and dataization.

3.1. Objects and Data

Definition 3.1 ().

An object is a set of ordered pairs $(a_{i},v_{i})$ such that $a_{i}$ is an identifier, all $a_{i}$ are different, and $v_{i}$ is an object.

An identifier is either $\varphi$, $\rho$, $\sigma$, $\nu$, or, by convention, a text without spaces starting with a small-case English letter in typewriter font.

The object at the line no. LABEL:ln:book may be represented as

(1) $$\begin{split}\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{book}&=\left\{\begin{matrix}[l](\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{isbn},\varnothing)\\ \end{matrix}\right\},\end{split}$$

where is an identifier and $\varnothing$ is an empty set, which is a proper object, according to Definition 3.1.

Definition 3.2 ().

An object may have properties of data, which is a computation platform dependable entity and is not decomposable any further within the scope of $\varphi$-calculus.

What exactly is data may depend on the implementation platform, but most certainly would include byte arrays, integers, floating-point numbers, string literals, and boolean values.

The object at the lines LABEL:ln:book2–2 may be represented as

(2) $$\begin{split}\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{book2}&=\left\{\begin{matrix}[l](\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{isbn},\varnothing)\\ (\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{title},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{"Object Thinking"})\\ (\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{price},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{memory})\\ \end{matrix}\right\},\\ \end{split}$$

where , , and are identifiers, is an object defined somewhere else, and the text in double quotes is data.

3.2. Attributes

Definition 3.3 ().

In an object $x$, $a$ is a void attribute with the name $a$ iff $(a,\varnothing)\in x$; it is an attached attribute with the value $v$ iff $\exists(a,v)\in x$ and $v\not=\varnothing$;

In Eq. 2, identifiers , , and are the attributes of the object . The attribute is void, while the other two are attached.

Definition 3.4 ().

If $x$ is an object and $\exists(a,v)\in x$, then $v$ may be referenced as $x.a$; this referencing mechanism is called dot notation.

Both void and attached attributes of an object are accessible using the dot notation. There is no such thing as visibility restriction in $\varphi$-calculus: all attributes are visible to all objects outside of the one they belong to.

It is possible to chain attribute references using dot notation, for example $\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{book2}.\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{price}.\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{neg}$ is a valid expression, which means “taking the attribute from the object and then taking the attribute from it.”

Definition 3.5 ().

If $x(a_{i},v_{i})$ is an object, then $\hat{x}$, a set consisting of all $a_{i}$, is its scope and the cardinality of $|\hat{x}|$ is the arity of $x$.

For example, the scope of the object at Eq. 2 consists of three identifiers: , , and .

3.3. Formation

Definition 3.6 ().

An object $x$ is abstract iff at least one of its attributes is void, i.e. $\exists(a,\varnothing)\in x$.

An alternative “arrow notation” may be used to denote an object $x$ in a more compact way, where void attributes stay in the parentheses on the left side of the mapping symbol $\mapsto$ and pairs, which represent attached attributes, stay on the right side, in double-square brackets. Equation 2 may be written as

(3) $$\begin{split}&\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{book2}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{isbn})\mapsto\llbracket\\[-4.0pt] &\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{title}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{"Object Thinking"},\\[-4.0pt] &\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{price}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{memory}\\[-4.0pt] &\rrbracket.\\ \end{split}$$

3.4. Application

Definition 3.7 ().

If $x$ is an abstract object and $y$ is an object where $\hat{y}\subseteq\hat{x}$, then an application of $y$ to $x$ is a copy of $x$, a new object that consists of pairs $(a\in\hat{x},v)$ such that $v=y.a$ if $x.a=\varnothing$ and $v=x.a$ otherwise.

Application makes some void attributes of $x$ attached—by binding objects to them. The produced object has exactly the same set of attributes, but some of them, which were void before, become attached.

It is not expected that all void attributes turn into attached ones during application. Some of them may remain void, which will lead to creating a new abstract object. To the contrary, if all void attributes are substituted with arguments during copying, a newly created object will be closed.

Once set, attached attributes may not be reset. This may be interpreted as immutability property of objects.

Arrow notation may also be used to denote object copying, where the names of the attributes, which remain void, stay in the brackets on the left side of the mapping symbol $\mapsto$, while objects $P$ provided as arguments stay on the right side, in the brackets. For example, the object at the line no. LABEL:ln:point-copy may be written as

(4) $$\begin{split}&\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{point}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{x}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{5},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{y}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{-3}).\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{distance}(\\[-4.0pt] &\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{to}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{point}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{x}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{13},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{y}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{3.9})\\[-4.0pt] &),\end{split}$$

and may further be simplified since the order of parameters is obvious:

(5) $$\begin{split}\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{point}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{5},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{-3}).\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{distance}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{point}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{13},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{3.9})).\end{split}$$

An application without arguments is a copy of an object. For example, in these expressions the attribute is attached to the same object as the attribute , while the attribute is attached to a new object, a copy of :

$$\begin{split}&\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{point}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{5},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{-3}),\\ &\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p1}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p},\\ &\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p2}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p}().\\ \end{split}$$

3.5. Formation

Definition 3.8 ().

The process of creating an object that is not a copy of another object is called formation.

Syntactically, object formation is denoted by double square brackets, as in Eq. 3, to the contrary of object application, which is denoted by round brackets, as in Eq. 4. Object abstraction is a special case of object formation. The following expression is a formation of the object $x$:

$$x\mapsto[[y->t]].$$

3.6. Parent and Home

Definition 3.9 ().

If $x$ is an object, then $x.\rho$ is its parent, which is the object that created $x$.

An object may be created either by abstraction or application. In case of abstraction, an object is created by another abstract object, for example:

(6) $$\begin{split}&x\mapsto\llbracket y\mapsto\llbracket z\mapsto t\rrbracket\rrbracket\\[-4.0pt] &x.y.\rho=x\\[-4.0pt] &x.y.z.\rho=y.\end{split}$$

In case of application, an object is created by the prepending object:

(7) $$\begin{split}&a\mapsto\llbracket b\mapsto c,d\mapsto e.f,g\mapsto h.i(j)\rrbracket\\[-4.0pt] &a.b.\rho=a\\[-4.0pt] &a.d.\rho=e\\[-4.0pt] &a.g.\rho=h.\end{split}$$

Definition 3.10 ().

If $x$ is an object, then $x.\sigma$ is its home object, which is the $\rho$ of the abstract object $x$ is a copy of.

For example:

(8) $$\begin{split}&x\mapsto\llbracket y(f)\mapsto\llbracket\rrbracket\rrbracket\\[-4.0pt] &x.y.\rho=x\\[-4.0pt] &z\mapsto\llbracket t\mapsto x.y(42)\rrbracket\\[-4.0pt] &z.t.\rho=z\\[-4.0pt] &z.t.\sigma=x.\end{split}$$

3.7. Decoration

Definition 3.11 ().

If $x$ and $y$ are objects and $x.\varphi=y$, then $\forall a(x.a=y.a)$ if $a\not\in\hat{x}$; this means that $x$ is decorating $y$.

Here, $\varphi$ is a special identifier denoting the object, known as a decoratee, being decorated within the scope of the decorator.

For example, the object at the lines LABEL:ln:circle–43 would be denoted by this formula:

(9) $$\begin{split}&\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{circle}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{center},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{radius})\mapsto\llbracket\\[-4.0pt] &\quad\varphi\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{center},\\[-4.0pt] &\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{is-inside}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p})\mapsto\llbracket\\[-4.0pt] &\quad\quad\varphi\mapsto\rho.\varphi.\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{distance}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p}).\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{lte}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{radius})\\[-4.0pt] &\quad\rrbracket\\[-4.0pt] &\rrbracket,\end{split}$$

while the application of it would look like:

(10) $$\begin{split}\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{c}&\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{circle}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{point}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{-3},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{9}),\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{40}),\end{split}$$

producing:

(11) $$\begin{split}&\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{c}\mapsto\llbracket\\[-4.0pt] &\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{center}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{point}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{-3},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{9}),\\[-4.0pt] &\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{radius}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{40},\\[-4.0pt] &\quad\varphi\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{center},\\[-4.0pt] &\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{is-inside}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p})\mapsto\llbracket\\[-4.0pt] &\quad\quad\varphi\mapsto\rho.\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{distance}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p}).\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{lte}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{radius})\\[-4.0pt] &\quad\rrbracket\\[-4.0pt] &\rrbracket.\end{split}$$

Because of decoration, the expression $\rho.\varphi.\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{distance}$ in Eq. 9 is semantically equivalent to a shorter expression $\rho.\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{distance}$ in Eq. 11.

The following expression makes a new object , which represents a sequence of object applications ending with a copy of :

(12) $$\begin{split}&\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{is}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{c}.\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{is-inside}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{point}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{1},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{7})),\end{split}$$

producing:

(13) $$\begin{split}&\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{c}\mapsto\llbracket\\[-4.0pt] &\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{center}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{point}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{-3},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{9}),\\[-4.0pt] &\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{radius}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{40},\\[-4.0pt] &\quad\varphi\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{center},\\[-4.0pt] &\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{is-inside}\mapsto\llbracket\\[-4.0pt] &\quad\quad\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{point}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{1},\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{7}),\\[-4.0pt] &\quad\quad\varphi\mapsto\rho.\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{distance}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{p}).\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{lte}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{radius})\\[-4.0pt] &\quad\rrbracket\\[-4.0pt] &\rrbracket.\end{split}$$

It is important to notice that attributes of a decoratee don’t belong to the scope of its decorator.

3.8. Atoms

Definition 3.12 ().

If $\lambda s.M$ is a function of one argument $s$ returning an object, then it is an abstract object called an atom, $M$ is its $\lambda$-term, and $s$ is its void attribute.

Atoms may have their $\lambda$-terms defined outside of $\varphi$-calculus formal scope. For example, the object at the line no. 51 would be denoted as

(14) $$\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{stdout}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{text})\mapsto\lambda s.M_{\texttt{stdout}},$$

where $M_{\texttt{stdout}}$ is a $\lambda$-term defined externally.

In atoms, $\lambda$-terms are attached to $\lambda$ attribute. Thus, a more formal form of the Eq. 14 is:

$$\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{stdout}\mapsto\llbracket\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{text}\mapsto\varnothing,\lambda\mapsto M_{\text{stdout}}\rrbracket.$$

3.9. Constant

Definition 3.13 ().

If $x\mapsto\llbracket y\mapstochar\relbar\mathrel{\mkern-8.0mu}\mapsto z\rrbracket$ is an object then $y$ is a constant attribute, meaning that the result of dataization of $x.y$ always equals to itself.

3.10. Identity

Definition 3.14 ().

If $x$ is an object then $x.\nu$ is a positive integer data object with a unique identity of $x$ in the entire runtime scope.

For example, without any other objects in scope it is safe to assume the following, however there is no guarantee that the actual numbers will be the same in all implementations:

(15) $$\begin{split}&\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{x}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{y})\mapsto\llbracket\rrbracket\\[-4.0pt] &\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{z}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{x}(\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{y}\mapsto\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{42})\\[-4.0pt] &\Phi.\nu=0,\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{x}.\nu=1,\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{42}.\nu=2,\vrule height=6.00006pt,depth=1.00006pt,width=0.0pt\textnormal{z}.\nu=3.\end{split}$$

4. Key Features

There are a few features that distinguish EO and $\varphi$-calculus from other existing OO languages and object theories, while some of them are similar to what other languages have to offer. The Section is not intended to present the features formally, which was done earlier in Sections 3 and 2, but to compare EO with other programming languages and informally identify similarities.

No Classes.  EO is similar to other delegation-based languages like Self (Ungar et al., 1987), where objects are not created by a class as in class-based languages like C++ or Java, but from another object, inheriting properties from the original. However, while in such languages, according to Fisher and Mitchell (1995), “an object may be created, and then have new methods added or existing methods redefined,” in EO such object alteration is not allowed.

No Types.  Even though there are no types in EO, compatibility between objects may be inferred in compile-time and validated strictly, which other typeless languages such as Python, Julia (Bezanson et al., 2012), Lua (Ierusalimschy, 2016), or Erlang (erl, 2020) can’t guarantee. Also, there is no type casting or reflection on types in EO.

No Inheritance.  It is impossible to inherit attributes from another object in EO. The only two possible ways to re-use functionality are either via object composition or decorators. There are OO languages without implementation inheritance, for example Go (Donovan and Kernighan, 2015), but only Kotlin (Jemerov and Isakova, 2017) has decorators as a language feature. In all other languages, the Decorator pattern (Gamma et al., 1994) has to be implemented manually (Bettini et al., 2011).

No Methods.  An object in EO is a composition of other objects and atoms: there are no methods or functions similar to Java or C++ ones. Execution control is given to a program when atoms’ attributes are referred to. Atoms are implemented by EO runtime similar to Java native objects. To our knowledge, there are no other OO languages without methods.

No Constructors.  Unlike Java or C++, EO doesn’t allow programmers to alter the process of object construction or suggest alternative paths of object instantiation via additional constructions. Instead, all arguments are attached to attributes “as is” and can’t be modified.

No Static Entities.  Unlike Java and C#, EO objects may consist only of other objects, represented by attributes, while class methods, also known as static methods, as well as static literals, and static blocks—don’t exist in EO. Considering modern programming languages, Go has no static methods either, but only objects and “structs” (Schmager et al., 2010).

No Primitive Data Types.  There are no primitive data types in EO, which exist in Java and C++, for example. As in Ruby, Smalltalk (Goldberg and Robson, 1983), Squeak, Self, and Pharo, integers, floating point numbers, boolean values, and strings are objects in EO: “everything is an object” is the key design principle, which, according to West (2004, p.66), is an “obviously necessary prerequisite to object thinking.”

No Operators.  There are no operators like or in EO. Instead, numeric objects have built-in atoms that represent math operations. The same is true for all other manipulations with objects: they are provided only by their encapsulated objects, not by external language constructs, as in Java or C#. Here EO is similar to Ruby, Smalltalk and Eiffel, where operators are syntax sugar, while implementation is encapsulated in the objects.

No NULL References.  Unlike C++ and Java, there is no concept of NULL in EO, which was called a “billion dollar mistake” by Hoare (2009) and is one of the key threats for design consistency (Bugayenko, 2016). Haskell, Rust, OCaml, Standard ML, and Swift also don’t have NULL references.

No Empty Objects.  Unlike Java, C++ and all other OO languages, empty objects with no attributes are forbidden in EO in order to guarantee the presence of object composition and enable separation of concerns (Dijkstra, 1982): larger objects must always encapsulate smaller ones.

No Private Attributes.  Similar to Python (Lutz, 2013) and Smalltalk (Hunt, 1997), EO makes all object attributes publicly visible. There are no protected ones, because there is no implementation inheritance, which is considered harmful (Hunt, 2000). There are no private attributes either, because information hiding can anyway easily be violated via getters, and usually is, making the code longer and less readable, as explained by Holub (2004).

No Global Scope.  All objects in EO are attached to some attributes. Objects constructed in the global scope of visibility are attached to attributes of the $\Phi$ object of the highest level of abstraction. Newspeak and Eiffel are two programming languages that does not have global scope as well.

No Mutability.  Similar to Erlang (Armstrong, 2010), there are only immutable objects in EO, meaning that their attributes may not be changed after the object is constructed or copied. Java, C#, and C++, have modifiers like , , or to make attributes immutable, which don’t mean constants though. While the latter will always expose the same functionality, the former may represent mutable entities, being known as read-only references (Birka and Ernst, 2004). For example, an attribute may have an object attached to it, which is a random number generator. EO won’t allow assigning another object to the attribute . However, every time the attribute is dataized, its value will be different. There are number of OOP languages that also prioritize immutability of objects. In Rust (Matsakis and Klock, 2014), for example, all variables are immutable by default, but can be made mutable via the modifier. Similarly, D (Bright et al., 2020) has qualifier , which expresses transitive immutability of data.

No Exceptions.  In most OO languages exception handling (Goodenough, 1975): happens through an imperative error-throwing statement. Instead, EO has a declarative mechanism for it, which is similar to Null Object design pattern (Martin et al., 1997): returning an abstract object causes program execution to stop once the returned object is dealt with.

No Functions.  There are no lambda objects or functions in EO, which exist in Java 8+, for example. However, objects in EO have “bodies,” which make it possible to interpret objects as functions. Strictly speaking, if objects in EO would only have bodies and no other attributes, they would be functions. It is legit to say that EO extends lambda calculus, but in a different way comparing to previous attempts made by Mitchell et al. (1993) and Di Gianantonio et al. (1998): methods and attributes in EO are not new concepts, but lower-level objects.

No mixins.  There are no “traits” or “mixins” in EO, which exist in Ruby and PHP to enable code reuse from other objects without inheritance and composition.

5. Four Principles of OOP

In order to answer the question, whether the proposed object calculus is sufficient to express any object model, in this Section we demonstrate how four fundamental principles of OOP are realized by $\varphi$-calculus: encapsulation, abstraction, inheritance, and polymorphism.

5.1. Abstraction

Abstraction, which is called “modularity” by Booch et al. (2007), is, according to West (2004, p.203), “the act of separating characteristics into the relevant and irrelevant to facilitate focusing on the relevant without distraction or undue complexity.” While Stroustrup (1997) suggests C++ classes as instruments of abstraction, the ultimate goal of abstraction is decomposition, according to West (2004, p.73): “composition is accomplished by applying abstraction—the ‘knife’ used to carve our domain into discrete objects.”

In $\varphi$-calculus objects are the elements the problem domain is decomposed into. This goes along the claim of West (2004, p.24): “objects, as abstractions of entities in the real world, represent a particularly dense and cohesive clustering of information.”

5.2. Inheritance

Inheritance, according to Booch et al. (2007), is “a relationship among classes wherein one class shares the structure and/or behavior defined in one (single inheritance) or more (multiple inheritance) other classes,” where “a subclass typically augments or restricts the existing structure and behavior of its superclasses.” The purpose of inheritance, according to Meyer (1997), is “to control the resulting potential complexity” of the design by enabling code reuse.

Consider a classic case of behaviour extension, suggested by Stroustrup (1997, p.38) to illustrate inheritance. C++ class represents a graphic object on the canvas (a simplified version of the original code):

⬇

51  Point center;

52public:

53  void move(Point to) { center = to; draw(); }

54  virtual void draw() = 0;

55};

The method is “virtual,” meaning that it is not implemented in the class but may be implemented in sub-classes, for example in the class :

⬇

26  int radius;

27public:

28  void draw() { /* To draw a circle */ }

29};

The class inherits the behavior of the class and extends it with its own feature in the method . Now, when the method is called, its implementation from the class will call the virtual method , and the call will be dispatched to the overridden method through the “virtual table” in the class . The creator of the class is now aware of sub-classes which may be created long after, for example , , and so on.

Even though implementation inheritance and method overriding seem to be powerful mechanisms, they have been criticized. According to Holub (2003), the main problem with implementation inheritance is that it introduces unnecessary coupling in the form of the “fragile base class problem,” as was also formally demonstrated by Mikhajlov and Sekerinski (1998).

The fragile base class problem is one of the reasons why there is no implementation inheritance in $\varphi$-calculus. Nevertheless, object hierarchies to enable code reuse in $\varphi$-calculus may be created using decorators. This mechanism is also known as “delegation” and, according to Booch et al. (2007, p.98), is “an alternate approach to inheritance, in which objects delegate their behavior to related objects.” As noted by West (2004, p.139), delegation is “a way to extend or restrict the behavior of objects by composition rather than by inheritance.” Seiter et al. (1998) said that “inheritance breaks encapsulation” and suggested that delegation, which they called “dynamic inheritance,” is a better way to add behavior to an object, but not to override existing behavior.

The absence of inheritance mechanism in $\varphi$-calculus doesn’t make it any weaker, since object hierarchies are available. Booch et al. (2007) while naming four fundamental elements of object model mentioned “abstraction, encapsulation, modularity, and hierarchy” (instead of inheritance, like some other authors).

5.3. Polymorphism

According to Meyer (1997, p.467), polymorphism means “the ability to take several forms,” specifically a variable “at run time having the ability to become attached to objects of different types, all controlled by the static declaration.” Booch et al. (2007, p.67) explains polymorphism as an ability of a single name (such as a variable declaration) “to denote objects of many different classes that are related by some common superclass,” and calls it “the most powerful feature of object-oriented programming languages.”

Consider an example C++ class, which is used by Stroustrup (1997, p.310) to demonstrate polymorphism (the original code was simplified):

⬇

55  string name;

56public:

57  Employee(const string& name);

58  virtual void print() { cout << name; };

59};

Then, a sub-class of is created, overriding the method with its own implementation:

⬇

29  int level;

30public:

31  Employee(int lvl) :

32    Employee(name), level(lvl);

33  void print() {

34    Employee::print();

35    cout << lvl;

36  };

37};

Now, it is possible to define a function, which accepts a set of instances of class and prints them one by one, calling their method .:

⬇

59  for (set<Employee*>::const_iterator p =

60    emps.begin(); p != emps.end(); ++p) {

61    (*p)->print();

62  }

63}

The information of whether elements of the set are instances of or is not available for the function in compile-time. As explained by Booch et al. (2007, p.103), “polymorphism and late binding go hand in hand; in the presence of polymorphism, the binding of a method to a name is not determined until execution.”

Even though there are no explicitly defined types in $\varphi$-calculus, the comformance between objects is derived and “strongly” checked in compile time. In the example above, it would not be possible to compile the code that adds elements to the set , if any of them lacks the attribute . Since in EO, there is no reflection on types or any other mechanisms of alternative object instantiation, it is always known where objects are constructed or copied and what is the structure of them. Having this information in compile-time it is possible to guarantee strong compliance of all objects and their users. To our knowledge, this feature is not available in any other OOP languages.

5.4. Encapsulation

Encapsulation is considered the most important principle of OOP and, according to Booch et al. (2007, p.51), “is most often achieved through information hiding, which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics; typically, the structure of an object is hidden, as well as the implementation of its methods.” Encapsulation in C++ and Java is achieved through access modifiers like or , while in some other languages, like JavaScript or Python, there are no mechanisms of enforcing information hiding.

However, even though Booch et al. (2007, p.51) believe that “encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation of concerns,” in reality the barriers are not so explicit: they can be easily violated. West (2004, p.141) noted that “in most ways, encapsulation is a discipline more than a real barrier; seldom is the integrity of an object protected in any absolute sense, and this is especially true of software objects, so it is up to the user of an object to respect that object’s encapsulation.” There are even programming “best practices,” which encourage programmers to compromise encapsulation: getters and setters are the most notable example, as was demonstrated by Holub (2004).

The inability to make the encapsulation barrier explicit is one of the main reasons why there is no information hiding in $\varphi$-calculus. Instead, all attributes of all objects in $\varphi$-calculus are visible to any other object.

In EO the primary goal of encapsulation is achieved differently. The goal is to reduce coupling between objects: the less they know about each other the thinner the the connection between them, which is one of the virtues of software design, according to Yourdon and Constantine (1979).

In EO the tightness of coupling between objects should be controlled during the build, similar to how the threshold of test code coverage is usually controlled. At compile-time the compiler collects the information about the relationships between objects and calculates the coupling depth of each connection. For example, the object is referring to the object . This means that the depth of this connection between objects and is two, because the object is using two dots to access the object . Then, all collected depths from all object connections are analyzes and the build is rejected if the numbers are higher than a predefined threshold. How exactly the numbers are analyzed and what are the possible values of the threshold is a subject for future researches.

6. Complexity

One of the most critical factors affecting software maintainability is its complexity. The design of a programming language may either encourage programmers to write code with lower complexity, or do the opposite and provoke the creation of code with higher complexity. The following design patterns, also known as anti-patterns, increase complexity, especially if being used by less experienced programmers (most critical are at the top of the list):

• P1: Returning NULL references in case of error
  (Hoare, 2009)

• P2: Implementation inheritance (esp. multiple)
  (Holub, 2003)

• P3: Mutable objects with side-effects
  (Bloch, 2016)

• P4: Type casting
  (McConnell, 2004; Gannimo, 2017)

• P5: Utility classes with only static methods
  (Bugayenko, 2016)

• P6: Runtime reflection on types
  (Bugayenko, 2016)

• P7: Setters to modify object’s data
  (Holub, 2004)

• P8: Accepting NULL as function arguments
  (Hoare, 2009)

• P9: Global variables and functions
  (McConnell, 2004)

• P10: Singletons
  (Nystrom, 2014; Bugayenko, 2016)

• P11: Factory methods instead of constructors
  (Bugayenko, 2016)

• P12: Exception swallowing
  (Rocha et al., 2018)

• P13: Getters to retrieve object’s data
  (Holub, 2004)

• P14: Code reuse via mixins (we can think of this as a special case of workaround for the lack of multiple inheritance)
  (McConnell, 2004)

• P15: Explanation of logic via comments
  (Martin, 2008; McConnell, 2004)

• P16: Temporal coupling between statements
  (Bugayenko, 2016)

• P17: Frivolous inconsistent code formatting
  (Martin, 2008; McConnell, 2004)

In Java, C++, Ruby, Python, Smalltalk, JavaScript, PHP, C#, Eiffel, Kotlin, Erlang, and other languages most of the design patterns listed above are possible and may be utilized by programmers in their code, letting them write code with higher complexity. To the contrary, they are not permitted in EO by design:

• , P• ‣ 6, P• ‣ 6 $\to$ There are no NULLs in EO

• , P• ‣ 6, P• ‣ 6, P• ‣ 6 $\to$ There are no static methods

• , P• ‣ 6 $\to$ There is no inheritance

• , P• ‣ 6, P• ‣ 6 $\to$ There are no mutable objects

• , P• ‣ 6, P• ‣ 6 $\to$ There are no types

• , P• ‣ 6 $\to$ There is no global scope

• , P• ‣ 6 $\to$ There are no exceptions

• , P• ‣ 6 $\to$ There are no mixins

• , P• ‣ 6 $\to$ Inline comments are prohibited

• , P• ‣ 6 $\to$ There are no statements

• , P• ‣ 6 $\to$ The syntax explicitly defines style

Thus, since in EO all patterns listed above are not permitted by the language design, EO programs will have lower complexity while being written by the same group of programmers.

7. Related Work

Attempts were made to formalize OOP and introduce object calculus, similar to lambda calculus (Barendregt, 2012) used in functional programming. For example, Abadi and Cardelli (1995) suggested an imperative calculus of objects, which was extended by Bono and Fisher (1998) to support classes, by Gordon and Hankin (1998) to support concurrency and synchronisation, and by Jeffrey (1999) to support distributed programming.

Earlier, Honda and Tokoro (1991) combined OOP and $\pi$-calculus in order to introduce object calculus for asynchronous communication, which was further referenced by Jones (1993) in their work on object-based design notation.

A few attempts were made to reduce existing OOP languages and formalize what is left. Featherweight Java is the most notable example proposed by Igarashi et al. (2001), which is omitting almost all features of the full language (including interfaces and even assignment) to obtain a small calculus. Later it was extended by Jagannathan et al. (2005) to support nested and multi-threaded transactions. Featherweight Java is used in formal languages such Obsidian (Coblenz et al., 2019) and SJF (Usov and Dardha, 2020).

Another example is Larch/C++ (Cheon and Leavens, 1994), which is a formal algebraic interface specification language tailored to C++. It allows interfaces of C++ classes and functions to be documented in a way that is unambiguous and concise.

Several attempts to formalize OOP were made by extensions of the most popular formal notations and methods, such as Object-Z (Duke et al., 2000) and VDM++ (Durr and Van Katwijk, 1992). In Object-Z, state and operation schemes are encapsulated into classes. The formal model is based upon the idea of a class history (Duke and Duke, 1990). Although, all these OO extensions do not have comprehensive refinement rules that can be used to transform specifications into implemented code in an actual OO programming language, as was noted by Paige and Ostroff (1999).

Bancilhon and Khoshafian (1985) suggested an object calculus as an extension to relational calculus. Jankowska (2003) further developed these ideas and related them to a Boolean algebra. Lee et al. (1996) developed an algorithm to transform an object calculus into an object algebra.

However, all these theoretical attempts to formalize OO languages were not able to fully describe their features, as was noted by Nierstrasz (1991): “The development of concurrent object-based programming languages has suffered from the lack of any generally accepted formal foundations for defining their semantics.” In addition, when describing the attempts of formalization, Eden (2002) summarized: “Not one of the notations is defined formally, nor provided with denotational semantics, nor founded on axiomatic semantics.” Moreover, despite these efforts, Ciaffaglione et al. (2003b, a, 2007) noted in their series of works that a relatively little formal work has been carried out on object-based languages and it remains true to this day.

8. Acknowledgments

Many thanks to (in alphabetic order of last names) Fabricio Cabral, Kirill Chernyavskiy, Piotr Chmielowski, Danilo Danko, Konstantin Gukov, Andrew Graur, Ali-Sultan Ki-gizbaev, Nikolai Kudasov, Alexander Legalov, Tymur $\lambda$ysenko, Alexandr Naumchev, Alonso A. Ortega, John Page, Alex Panov, Alexander Pushkarev, Marcos Douglas B. Santos, Alex Semenyuk, Violetta Sim, Sergei Skliar, Stian Soiland-Reyes, Viacheslav Tradunskyi, Maxim Trunnikov, Ilya Trub, César Soto Valero, David West, and Vladimir Zakharov for their contribution to the development of EO and $\varphi$-calculus.