ReRe: why isolated components

[Laszlo Varga]

Hello,
thanks for the "answer". Right, isolation reduces the (possible) complexity,
but is that the motivation for the wrapper project? For coping with complexity
we have several other isolation technics, like namespace, functions, or 
objects. Part of the mail thread showes that the main motivation is to cope
with the "dynamic complexity". (Reduing the number of states, I mean).
Other reflections say that it is for robustness.

Other benefits that not mentioned are the reusability, the cooperation of
programmers, the testabilty, and ....

I guess that everybody who started programming knows these benefits in general.
There are many tools and paradigmas to support this idea.
But now, people seems to start thinking something new,
and I wanted to provocate them to try to be precise at the start.
I know well that it is hard. But also had bad experience when ommited
this hard phase.


So what we (Joe) want?

Robust system?
Real time system?
Open system?
Replacing CORBA.
Supervised components?
Standardised components?
???
???
???

All of them?

Cheers
Laszlo
-------joachim.durchholz wrote------------------------
> Laszlo Varga wrote:
> > Really, why?
> > What are the (main) motivations for kind a system?
> 
> Let me rephrase, in the hopes that I understood your question correctly:
> What is the main motivation for isolating components?
> 
> The answer is simple. If you double the number of names in a program, 
> the number of unwanted possible interaction quadruples. More generally, 
> for N items, you have N*(N-1)/2 possible interactions.
> 
> The number of *intended* interactions between components grows roughly 
> linearly (I think it's usually on the order of N*log(N), but whether 
> it's really linear or not doesn't matter: the main point is that the 
> number of wanted interactions is massively less than O(N*N)).
> 
> In other words, the number of unwanted potential interactions grows in 
> an approximately quadradic correlation with program size.
> 
> To keep the number of potential interactions down, Parnas propagated 
> "information hiding", cutting down on the number of interactions that a 
> compiler will allow. (Information hiding is not intended to prevent 
> programmers from looking into components, its for preventing components 
> from looking into other components.)
> 
> Just my thoughts on the subject.
> HTH
> Jo
>