Programmer’s Blog

Correlation

I got an idea that there is a big similarity between iEditor, that I presented in the first series of articles, and general Source Control systems as well known and used. There is no need to create a new specific system. It is enough to utilize current source control systems principles and algorithms and use them the way that they offer the possibilites I presented. Layers of history, as stored in source control systems, have a lot in common with idea layers as I introduced.
There could be one system, maintaining both, the historic layers and idea layers. That would mean just extension of Source Control systems agenda.

22. 7. 2018 | ctverec F1 | 0

Two sides of program code

What I wrote at the end of the last post wouldn’t be true if OOP was more complicated than non-OOP, like it was some artificial construct. Just opposite, it is true because OOP is closer to natural human way of thinking than non-OOP. To realise and appreciate this we have to understad the difference between the principle of human way of thinking and machine / computer way of thinking.

We can tend to mistakenly think that computers ‘think’ similar way as humans. Isn’t it true that human brain can emulate processor way of thinking? And isn’t it true that a computer can emulate humans behaviour? They both are true. But we have to emphasise the word “emulate”. And to emulate means to imitate. In fact we are good in human’s way of thinking and computers are good in their own style of thinkig. The most obvious difference is that computer doesn’t have a clue what it is doing. It just processes bunch of instructions in a microfraciton of time and that is all. If we play tennis against a wall and it returns the ball back to us, we could tend to think there is someone alive playing against us. Luckily it is quite obvious that the wall is not alive. With computers it is not so obvious. What doesn’t mean they aren’t perfect toys.
Back to our topic. Computer ‘thinks’ it’s own way. And we write programs for it to make it behave as we need. Thus we create canvases of code for the machine to make it behave as we want. Have you ever seen pure machine code? You probably did. Just numbers. It is what machines like. Yum, yum, yum… We humans don’t. Ugh, ugh, ugh… For us this form is not understandable. And even if some of us pay the effort, learn it and claim they can understand it, we will argue that this form is not natural for us. We need something more human. So symbolic instructions languages (assemblers) were designed. Then first generation of higher level programming languages, then second and so on. Why? Because of the machine? No. On the machine side nothing changed. Only the diameters, volumes and speed. As concerns quality no changes. So why other and other generations of programming languages were created? Because there was need to bring programming closer to human. To make it more understandable. The more understandable you make the programming, the more effective programmer you are and the more ambitious projects you can start. With pure machine languages you could never do things as we have everywhere around today.

Program code has two sides. The machine side and the human side. Or better just opposite. The human is first. First we have an idea, second we can convert it to the form processable by computers. Each code is millon times processed from both the sides. From the computers’ one as it is run again and again (when we test if it realy does what we want) and from the human’s one, as it is observed again and again by the programmer to re-understand it, to work on it, to finish it, to extend it, to correct it etc. And the way how it is being perceived from each of the sides is different. So when we write a code, we do two things in one.
We as programmers by default know that the first goal we need to reach is to make our program running correctly. What means we concentrate at the computer’s side of the code. It is our primary goal. So we use the human side of the code as a tool to reach our goal on the machine’s side. In such a case we can underestimate the human’s side. And if not underestimate, then at least not appreciate enough. I don’t say we can not to appreciate it. I say just “not enough”. Human’s is never derived from machine’s. It only can happen that machine’s is derived from human’s.

17. 7. 2018 | ctverec F1 | 0

OOP - Interface

In non-OOP languages the official top most unit of ‘interface’ is a procedure or a function. Such a unit is offering a data manipulation. Specific format data manipulation or a processing. In OOP the essential unit of interface is - interface. Something more complex. It is not a unit of manipulation, it is a unit of purpose. Purpose generally is something more than just manipulation. Purpose can be something more abstract and something more philosophical than just straightforward manipulation. They say that OOP comes with (higher level of) abstraction. It is so.

interface PersonalData {}

interface Office {
void ProcessPersonalData(PersonalData data);
}

You can never do something like this in non-OOP language. In OOP it is very correct. And yet no object nor specific data type on the scene.

Interface splits world into two parts. Part of a “user” and part of a “performer”.

Though both these sides have their responsibilities, interface re-presents mainly proposal of responsibility of the performer side. Generally the performer side is a unit with certain character. This character is imprinted into the interface and promises certain behaviour.

Important is, that the performer unit is generally independent on the interface itself. In practice the unit can be a static class (then the interface is inseparable from the performer) or a dynamic (representation of class) object, what is more interesting possibility, though both the variants are relevant

because in case of using interface dynamicaly, we can use object of different class type and connect it to the same interface (interchangeability)

We can even use object of descendant class extending the interface and connect it to our interface

We can switch objects connected to an interface dynamicaly in runtime (interchange)

We can have classes / objects implementing more than one interface, thus agregating more than one character and utilization (multiple inheritance)

All of this makes Interface term centerpiece of OOP approach and makes OOP more advanced and powerful than non-OOP.

12. 7. 2018 | ctverec F1 | 0

Multiple Inheritance

If you think about the concept introduced, you soon find the main bottleneck. It is the conservative inheritance ordinance, that you can inherit (define interchangable class) just from one predecessor (single inheritance). Then you could build just tree hierarchies of classes what would be limiting.

In such a case for any existing class you would have just one linear definition path (path to base class alone) and you could never fully utilize the potential hidden in the concept. It is why real OOP languages come with multiple inheritance (either from classes or at least from interfaces) that allows us to freely (as needed) connect and share classes characteristics.

10. 7. 2018 | ctverec F1 | 0

Temporary Interchange

Interchangability as was introduced in the last post could be interpreted like one-way transformation. But we know that it is not the case. When we have
B : A
A a
B b

and make an assignment
a = b

we have object of type B in the variable of type A. Now we can manipulate object B like it was object A. For example

a.CallMethodOfClassA()

Now object which was originaly of type B is treated as if it was of type A, what means reduction of it’s itnterface to A form (subset of B). But what is important, there as well is a way back:

b = a // ??? no, we can’t do this

but we can make this

b = a as B // in the case we know there is an object of type B in the variable ‘a’

In other words, putting object B into variable of type A doesn’t reduce it. It just changes the view at it. So the interchange can be just temporary. If one-way interchange gives us some nice possiblitites reversible commutation makes such approach perfect. What is such bidirectional exchange useful for? Generaly for two types of operations:

1. Higher level operations (operations offered by interface of A are ‘higher level’ from perspective of B)

Let’s note that in such operations big role is played by virtuality, thus possibility to re-define body of methods in a descendant (interchangable class).

2. Transfer

This concept allows us to design and use families of classes which can be processed on a platform of intersection of their characteristics by program modules which don’t need to be modified specificaly for each individual class type. This is extremely ellegant and effective approach that elevates us one level higher above possiblities offered by bare non-OOP approach.

8. 7. 2018 | ctverec F1 | 0

OOP - Interchangeability

There are definitions and descriptions of Object Oriented Programming (OOP) and they work somehow. They talk about objects, classes, encapsulation, inheritance, polymorphism, abstraction and maybe something else, but none of them refers to one aspect of OOP which I think is essential. An aspect, that makes OOP really more useful and effective for building software systems than non-OOP. An aspect that was not introduced by OOP, but that was made by OOP a handy tool. The aspect mentioned is Interchangeability.

In our context we are talking about class (or object) interchangeability. It has something to do with compatibility. Let’s look at it more detaily.

A bit of math now

Definition 1: Class outer type is a set of declarations of it’s public members (data members and methods including their parameters) containing their types and names.

Class outer type is called class interface. They are synonyms. Careful, class type is not the same as class outer type. Class type is a synonym to class. See later.

And now interchangeability itself:

Definition 2: Class B is interchangeable with class A and we write B : A when (whole) outer type of class A is a subset of outer type of class B.

Definition 3: We call elements of a set of classes classes mutualy interchangeable with class X, when each class of the set is interchangeable with class X.

These definitions have consequences. First consequence is that class A is interchangeable with class A. Second consequence is that when B : A for B <> A, then never applies A : B. It looks theoretical. But it has a practical significance, when you have classes in a program where descendant doesn’t extend interface of it’s predecessor, so they have ‘like’ the same interface, the interchangeability is still one-way, not symetrical.

When we apply defintion 3 to 2, then we could say, that for B : A, A and B are mutualy interchangeable, what could sound like symetric relation, but it is not symetric due to there must be the supplement with A.

As well applies that when C : B and at the same time B : A, then definitely C : A. It follows from set definition of interchangeability.

Now more practical view.

Example 1: When

B : A
C : B
D : B

then A, B, C, D are mutualy interchangeable with A
B, C a D are mutualy interchangeable with B
but as well for example B and D are mutualy interchangeable with A

Example 2: When we have classes B : A and we define for them variables ‘a of type A’ and ‘b of type B’, thus

A a
B b

from definition 3 we can define an assignment

a = b // so ‘a’ can refer to an object of interchangeable class, because B is interchangeable with A

and at the same time it applies that we can’t make an assignment

b = a // because A is not interchangeable with B

This applies to program code. There is interchangeability that applies to objects in running system. In fact they both are different demostrations of (one) interchangeability principle.

It is instantiability (ability to create any number of instances of a class) together with interchageability what makes OOP much more powerful than non-OOP.

And what relation is between class type and the class outer type? Following

class X type : class X outer type

Class is a specific implementation of it’s (implicit) outer type. We can see that class outer type (class interface) plays quite an important role in the context of OOP. So when we talk about OOP, we can’t omit this term.

1. 7. 2018 | ctverec F1 | 0