From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,158ce2376534c35d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!h9g2000vbr.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Derived private interface Date: Tue, 9 Aug 2011 14:10:11 -0700 (PDT) Organization: http://groups.google.com Message-ID: <4a4f185d-5268-4d73-a5df-8149bd117e0f@h9g2000vbr.googlegroups.com> References: <27656578-65aa-48b9-9f89-4ebd4e0cb02a@glegroupsg2000goo.googlegroups.com> <0fe3b0f8-c064-444d-899d-640e891b58c3@w4g2000yqm.googlegroups.com> <128d8eb5-1cc6-47e3-a09b-b53a5ef289ce@m10g2000yqd.googlegroups.com> <4e141501$0$6629$9b4e6d93@newsspool2.arcor-online.net> <4b2728fc-6127-45d8-a314-9fc491701c26@g12g2000yqd.googlegroups.com> <82vcve4bqx.fsf@stephe-leake.org> <4e15b223$0$6541$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: 83.3.40.82 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1312924212 3965 127.0.0.1 (9 Aug 2011 21:10:12 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 9 Aug 2011 21:10:12 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: h9g2000vbr.googlegroups.com; posting-host=83.3.40.82; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUALESNKRC X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13,gzip(gfe) Xref: g2news2.google.com comp.lang.ada:21471 Date: 2011-08-09T14:10:11-07:00 List-Id: On Jul 29, 1:24=A0am, "Randy Brukardt" wrote: > >Did you try that with web servers? > > Fasinating. While I agree with most of your points, it is interesting tha= t > the web server that runs the AdaIC archive site, [...] > the specialty handlers (like the search engine) are all > called from case statements driven from those data tables. I assume that this particular web server was written from scratch and on top of some lower-level primitives (sockets). That's OK, but very likely an overkill. That's why I have mentioned the possibility to integrate off-the-shelf components, in which case there is simply no place to put your case statement. > The design was driven by an extra-paranoid approach to security: if the > server had any way for a URL to execute foreign code (a plug-in), I don't see any conflict between OOP and security here. The complete application can be statically bound, in which case the execution of dynamically loaded code is excluded. What I'm talking about is a kind of dependency inversion - instead of the web server calling each particular module from some single giant case statement (which has to with all packages, etc.), you might have a set of modules that register themselves in a single registry, which is later used to resolve the call. By doing this, the web server and its registry do not have to with anything other than the common interface specification. Of course, you might still need to do some magic in order to force all those modules to elaborate/initialize (so that they can register in the web server central module), which might turn out to be a ladder of with clauses that we wanted to avoid in the first place, but this has nothing to do with OOP - it is only a peculiarity of Ada and I can imagine a language where this can be done externally by a build script or even by a mere presence of source files. We can also think about the automated generation of the with statements that are need to force the elaboration of all modules. But then - the giant case statement can be also automatically generated, which could in turn be taken as an argument against OOP. Oh, dear... :-) Still, I believe that the open/close principle and the dependency inversion are two (only?) good use cases for dispatching and that when this design approach is needed, the dispatching offers the cleanest solution. -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com