Scribd
Upload
49 views3 pages

Upgrading OOP

The document proposes two upgrades to object-oriented programming (OOP): 1) Allowing class properties to store information about inherited classes to replace the "extends" directive, and 2) Adopting a functional programming approach where properties are mutually dependent and automatically updated. It provides an example classification tree diagram and experimental data format to visualize these proposed upgrades.

Uploaded by

ivanvodisek7727
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
49 views3 pages

Upgrading OOP

The document proposes two upgrades to object-oriented programming (OOP): 1) Allowing class properties to store information about inherited classes to replace the "extends" directive, and 2) Adopting a functional programming approach where properties are mutually dependent and automatically updated. It provides an example classification tree diagram and experimental data format to visualize these proposed upgrades.

Uploaded by

ivanvodisek7727
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

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;
];
}

You might also like