Upgrading Oop

Upgrading OOP Object oriented programming (OOP) is today's most popuar way of programming. System of classes that inherit properties from their parents simply hypnotizes user with it's intuitivity. Still, I recommend couple of upgrades:

1. Property Can Store Information About Inherited Class When defining class, it's properties could store informations about classes that defined class inherits. That kind of properties would completely replace use of classic “... extends ...” directive known from Java. According to my data, this upgrade doesn't reduce descriptivity of OO system in which it is implemented. According to my believes, this uprade simplifies programming by terminating need to use “... extends ...” directive. Possibility of visualization represented by following diagram was one of main reasons for creating this text.

Classification tree of objects is shown on the left side of the diagram. I'll call verticaly oriented properties with the name classification bases. The right side of the diagram reflects properties of cassification tree's elements. Contents of classification bases replace informations in above named “... extends ...” directives.The diagram shows proccess of propertie's inheritance by classification bases. Of course, chosen classification bases are not static. It means that they can be replaced by any other properties of relevant classes. By this kind of transformation, real data is not changed. The only change is in visualization of that data. Right side visualization of inheritance and propertie's data is updated accordingly to the choice of classification bases that make some classificatin tree.

1

2. Migrating To Functional* Concept Today's domination of imperative programming languages can't be denied. Imperative languages are caracterized by executing line-by-line list of commands. Functional* approach is relatively little used in programming today. In contrast to imperative languages, programs in functional* languages represent some sort of big static formula. Variables in that big formula can be mutualy depended. When altering one variable, other variables which depend of altered variable, should change their value. Functional* language programs can be compared to any x-office table calculators. Use of mutualy depended properties (functional* model) can completely replace use of methods known from imperative OOP languages. This statement is based on similarity of today's general theories of knowledge to functional* programming languages. General theories of knowledge (i.e. Type Theory) succeded to define Mathematics and other sciences. Functional* approach in OOP woud be in extending definition of properties, so they can besides explicit objects, contain calculated data and filtered lists of objects from other classes. Extended definition of properties would take arguments similar to these in this SQL statement: “SELECT props FROM class WHERE condition”. Proposed fuctional* approach is recommended to describe only dependance among user's class properties. That recommendation brings a need for some event processor which inserts, updates and removes database objects. This kind of implementation of dynamics is just rough estimation of what can be already done today, so the future is yet to be seen. *term “functional” covers mutualy linked and automaticaly updated variables

Appendix: Experimental Data Format Explaining a new experimental format, some definition fragments of above diagram are shown together with partial definition of the exprimental format itself. Selectors for range of objects are not shown here. Formatting rules are: 1)

Square brackets hold possible choice of classes that can be associated with a property.

2)

Curly braces hold extended properties of associated class.

3)

Left side of the colon (optional) holds a name required for reaching and overloading classes.

4)

Right side of the colon holds the name of associated existing class.

5)

Class names are written with capital first letter.

6)

Property names are written lowercase.

7)

Objects are not shown here. Just classes.

above example of visualization coded: Person :New { name [:String;]; surname [:String;]; 2

};

profession [ Medic :New { specialty [:String;]; }; Pilot :New { time driven [:Numeric;]; vehicle type [ Airplane :New { engine type [:String;]; wing length [:Numeric;]; }; Helicopter :New; Rocket :New { range distance [:Numeric;]; }; ]; }; Programmer :New { language [:String;]; preoccupation [:String;]; }; ]; species [:String;];

partial self definition: Root :New { classes [ Item :New { name [:String;]; inheritFrom [:String;]; properties [ :New { name [:String;]; type [:classes;]; next [:properties;]; }; :Null; ]; }; Next :classes; :Null; ]; objects [ item :classes next :objects; :Null; ]; }

3