Re: Derived private interface

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

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:f44209e4-8677-4995-8b17-d641bae2b698@hl8g2000vbb.googlegroups.com...
>On Aug 11, 12:21 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
>> But adding new modules without somehow modifying the web server is simply
>> not allowed in the problem statement that I had (that is, all code that 
>> the
>> server can execute is statically compiled into the web server).
>
>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, but they aren't practical for a no-budget project 
(certificates and encryption aren't cheap).

>The advantage of OOP is in its run-time nature. That is, the registry
>can be modified at run-time according to anything from startup options
>to real-time data input. Modifying a giant case statement (or is it a
>chain of ifs? after all, URLs are not discrete in the Ada sense) might
>be acceptable between deployment cycles of the given system, but
>making this structure dependent on some run-time values would be too
>much.

Well, actually, the URL mapping (URL to key mapping is stored in a data 
table - of ordinary records) was intended to be a run-time data structure. I 
never actually implemented run-time changes for that table, but it would be 
simple to do so. The "requirement" that I started with is that no code 
outside of that known to the web server could be executed, but of course 
that has nothing to do with the mapping of the URLs to those existing 
routines.

Adding a new module requires modifying the case statement, but that would 
require modifying a with clause and recompiling in any case. Don't see any 
difference there.

Anyway, I think I've said everything on this topic that needs to be said. 
There is no one right answer to program design challenges -- only that no 
design at all is wrong!

                                          Randy.