Re: New ProjectCenter Icons

[Richard Frith-Macdonald]

On 14 Sep 2007, at 08:34, Dr. H. Nikolaus Schaller wrote:

> And (I think I am repeating myself): what happens if the other  
> application is not available for some reason (hangs, crashed, etc.)  
> and DO access fails. You have to take care of these situations and  
> provide a fallback, which expands the code and complexity of the  
> module-applications again.

Actually that's not the case any more than within a monolithic app.   
Methods can fail whether via DO or not, and the code has to handle  
such error conditions whether via DO or not.  In fact the error  
handling situations are the same whether you are using DO or not  
(NSException and checking return values from methods).
Arguably it's actually slightly simpler via DO as the ability to set  
a timeout on a connection is a standard feature built in to DO, so if  
you use DO you don't need to write your own code to handle the case  
of a method which hangs/takes too long.

> Conjecture: separate applications communicating through DO need  
> more memory and are slower than a monolithic application (on a  
> single-processor system).

Sure, that's a no-brainer, but in practice should be irrelevant  
because in any decently designed system the DO is used for little  
things (like saying that a particular source file has been selected)  
where the overhead of DO is a tiny tiny fraction of a percent of the  
overall operation of each app.

Actually, this relates to a big advantage of ObjC design philosophy  
over C++ design philosophy.  In ObjC good design is to have fairly  
substantial classes which do a lot of work internally and have a  
simple external interface (because the messaging overhead is larger  
than function call overhead).  In C++ design you are encouraged to  
have small classes which do very little work, because the books tell  
you that the method call overhead is very small.  This leads to  
greater complexity and poorer maintainability in C++ code.   Use of  
DO emphasises the need for discipline in the design of external APIs  
to avoid performance problems, and this pays off in maintenance and  
feeds back to improved design of non-DO code too.