Re: Derived private interface

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:970ef0a5-da4b-4463-b411-aa3ef116fad1@f7g2000vba.googlegroups.com...
On Aug 12, 6:43 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

>> >I see - but isn't it a special case?
>>
>> Yes, in today's world, safety and security are surely a special case -- 
>> hardly anyone seems to care, and thus they get PWNed all the time.
>>
>> Yes, of course there are ways to enforce safety and security in a dynamic
>> loading environment,
>
>Never in my posts I have mentioned dynamic loading of anything (in
>fact, I have always stressed that the whole program can be compiled
>and linked statically) and I think that your focus on safety and
>security in this discussion is artificial.

Your previous message had expounded on the advantages of run-time management 
of modules. I had assumed that you suddenly were talking about dynamic 
module management, because I had already shown (twice in fact) that there 
was no advantage in this system to run-time management (or any other OOP 
characteristics) in terms of effort to add new interfaces.

Perhaps you've missed a critical point: static binding should always be 
strongly preferred to any sort of run-time management, because it is many 
times easier to analyze statically (both by tools and by the programmer), 
it's easier to debug (because the run-time management doesn't interfere with 
determining what the system is actually doing), and it typically performs 
better (because compilers can do better optimizations, although this effect 
is usually marginal and is far below the importance of the first two). These 
are critical to program maintenance, especially when having to understand 
existing code (even code you wrote when you come back to it 10 years later).

There has to be a strong reason for using dynamic module management:

(1) The interface is complex and interrelated, so that dynamic dispatching 
actually buys something beyond confusion (for instance, the "action 
routines" of Claw for handling events);
(2) Dynamic loading/reconfiguration of capabilities has to be supported;
(3) Following OOP religion even when it demonstratably doesn't help is more 
important than the benefits of a fully static design (a so-called 
"object-based design").

I'd previously shown repeatedly that (1) did not apply to the web server 
problem (at least with the design we selected); thus I had assumed that 
you'd veered off into discussing (2) -- because otherwise you are simply 
following (3) and there is no point in discussing anything with a religious 
fanatic (of any stripe) -- they don't really care about facts.

So at this point it is clear that we really have nothing to talk about. 
Sorry.

                                        Randy.