OOP cannot Emulate True Component Oriented Programming

If underlying programming paradigm do not support higher-level abstractions, it would become practically impossible to implement such higher-level concepts and abstractions. The Components are higher-level abstraction to the Objects. Therefore, it is impractical to stretch the OOP or Object-abstraction to more than one layer to get a workable Component abstraction (e.g. Component Oriented Programming).

There is great parallel in the past, which provides an excellent example and explanation to this problem. We know structured programming has lot of benefits over nonstructural-programming. However, earlier programming languages, such as, FORTRAN-4 did not support it (i.e. structure or records). For example, if we try to emulate the Structured paradigm in FORTRAN, what would happen? Consider a simple example of a structure (in ‘C’ or Pascal’s ‘Record’) for the Employee. Lets assume it has five fields: Name, Salary, Age, Phone, and Social-Security Numbers.

In the Structural-Programming this can be unified into “indivisible” unit. (Sorry, for the use of the word “indivisible”, I have to find a better word for it. Here it means, for most practical purposes it could function as a variable or could be handled or operated as a physical unified-unit).

However, it might be possible to emulate the “structure” in nonstructural Programming, by declaring and keeping all the variables of a structure together. But they are not a physically unified-unit (i.e. they cannot be operated through a "unified handle"). If one needs to pass an array of Employees to a function, he would end up creating five arrays, one for each field in the structure.

Exceptions and problems start emerging for simple operations. If a structure has 20 fields and a function may need to use only 5 fields, he would only pass five arrays. “Employee Structure” is already fractured. What happens, if one of the functions needs 2 more fields for next release? He ends up changing parameters for many functions in the chain of function calls (results in many changes at many places).

What would happen, if we need to create structural hierarchy? For example, if one or more fields in the structure are again a structure with 5 fields each. How does any one maintain the “indivisibility” and logical-hierarchy of the structure?

How one can possible manage, if one of the fields is a variable length array?

How can he pass an array of such structures? The harder we try, the stranger mess the code would become. For large applications, the code becomes, incomprehensible, if dozens of people working on the project. The exceptions and workarounds would be subjective to individual diverging interpretation that would create fiction. No two people would think or do in same way.

Imagine, the mess, if we have to negotiate and document, which part of each structure (and its substructures or arrays) need to pass to each function. How do we handle, if one of the fields in the structure is a variable length array of sub-structures? (e.g. List of subordinates). No one would know, what he might need in the future updates. How do we add 2 more fields to a substructure? Imagine the mess it creates, if you have to update all the functions in the chain to deliver them to appropriate location/function-body for proper manipulation. We would be better of, if we create a best possible design that not necessarily emulate the Structured-abstraction.

An ideal component paradigm needs “indivisible” encapsulation (i.e. unified handle), an abstraction that could be handled as a physical-unit. Also, one should be able to build component-hierarchy; as we could build “structure-hierarchy” that preserves encapsulation of the structure and can be operated through "handle", even if it contains sub-structures, variable length arrays or even arrays of sub-structures. 

If one starts to break the structures to create the same in FORTRAN, it would end up with so many exceptions that are subject to individual interpretations. It would be a mess, which is the state of the OOP today. How is it possible to emulate the "structured-hierarchy" without physical encapsulation of variables? Likewise it is impossible to build component-hierarchy without physical encapsulation of Objects.

P.S: Please read the argument carefully and map it against your experiences. We explained why "Component-hierarchies" are essential for a viable CBSDF. I know this assessment is right. Can you find any apparent flaw in the argument? However, I understand, if you cannot bet on their validity. If you are skeptical, I like to know, could you feel, it is convincing enough or highly plausible to explore further?

A win-win proposition: If any one willing to help prove the technology to the world, Pioneer-soft is willing to grant exclusive-license in select few verticals. Both could win by driving the competition out-of-business. There is no better proof than driving the competing-application out of business, if it uses alternative technology. To start, they must spend time to understand the proof for themselves or allot couple of days time for Pioneer-soft to show conclusive proof. Absolutely there is no obligation, if they are not fully convinced after the initial evaluation.

Dr. Vinton Cerf (founding father of Internet) says that 99% of the internet applications yet to be invented. Our GUI-API is indispensable for building emerging online GUI applications.

If I am right (and I believe that I am absolutely right), we can save billions of dollars a year to the world economy. The US alone spends about $250 billion a year on IT applications. Not only this, it could have far reaching implications: For example, It gives a new perspective for the researchers to invent next generation platforms, CASE-tools and programming languages to help us build "replaceable-containers" for the higher level abstractions (that eliminate costly irrational dependencies).

I think, one should use the components and the component process for few weeks to see and experience the difference. Once, one gains experience he likely would never go back to painful manual spaghetti coding of Objects to build the online application. As you know, once you get used to Structured programming or OOP, it is impossible to go back to FORTRAN-4, especially to build large million line business applications. You should consider this argument in the context of large applications and not in the context of small applications that need effort of just few man months.

If you are wondering, how this applies to our CBSDF. As you know, the data structure offers physical-encapsulations to group of variables. This allow you to build data structure hierarchies. Likewise, the CF offers encapsulation of replaceable parts to operate on components/component-arrays, which allow us to create larger and larger component-hierarchies (since, each CF may contain many sub-CF and so on).

The component technology offers many fringe benefits as well. For example, as you may know, emerging processors/CPUs (or Nvidia GPUs) are moving in the direction of the multi-core. Not just Intel and AMD; but look at the ‘CELL’ processor with 10 PowerPC cores from IBM and Sony consortium. (Latest news: Intel shown a low-power teraflop supercomputer on a chip, which contains 80 cores).

Guess what. The components are asynchronous. We can run each component one a ‘Core’/’Thread’. For example, each character such as a Jet fighter or helicopter in a game (or real-time modeling of a battlefield) can be assigned to a 'Thread'.

We need to worry about only 1%-2% of the code (e.g. service request/response between the components in Fig#3) to synchronize the communications. On the other hand, the OOP extensively uses tightly coupled Objects , Object-sharing [Fig#1] and unstructured data-exchange (e.g. from DB-Object to Pie-chart), which makes very hard for the asynchronous or parallel execution of each object on a separate thread.