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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!aioe.org!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Derived private interface Date: Wed, 10 Aug 2011 17:21:37 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: 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> <4a4f185d-5268-4d73-a5df-8149bd117e0f@h9g2000vbr.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1313014900 16734 69.95.181.76 (10 Aug 2011 22:21:40 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 10 Aug 2011 22:21:40 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Xref: g2news2.google.com comp.lang.ada:21489 Date: 2011-08-10T17:21:37-05:00 List-Id: "Maciej Sobczak" wrote in message news:b6049447-8479-46ca-82e8-b6031a4b4d1a@q15g2000yqk.googlegroups.com... On Aug 9, 11:35 pm, "Randy Brukardt" wrote: >> I don't see any dependency inversion in the web server. (The web server >> calls packages to evaluate particular commands or operations -- that's >> how >> almost all programs work!) > >The dependency inversion is in the fact that the web server does not >have to know the modules it is calling. It is enough if the modules >know the web server (and its registry, to be exact) - thanks to this >new modules can be added without touching the web server itself >(that's the open/close principle at work now). What is needed for the >dependency inversion to work is a spec of something common - in the >case of OOP this is an interface. 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). So there can be no "inversion" here -- some piece of the server needs to know about all of the code that it possibly can execute. (Ada requires with clauses at a minimum.) >> This sounds more like a case of trying to make >> everything look like a nail (to the OOP hammer). > >No, this is trying to reduce the effort to maintain a heavy component >that is tested and verified only once. I have no idea what you are talking about; no part of my web server (other than the case statement) is modified to add a new capability. [Note that something list the case statement has to exist in the OOP model anyway - ,at a minimum for with clauses and a series of registration calls (there is insufficient control over elaboration in Ada to use elaboration for that purpose in a real system).] I can explain the mechanism in a bit more detail. The web server has a data list of (normalized) URLs that require special handling, along with a special handling key. When the web server sees any of these, it calls the special handling interface routine (passing the record containing the GET parameters and the output socket). Otherwise, it tries to serve a normal web page. The special handling interface contains a case statement on the special handling keys, and calls the appropriate handler for each one. Since the original requirement was for all of the code to be statically compiled, that code is also part of the web server executable, and of course the special handling interface needs to be modified to add a new module. But it (and the data table) are the only things that need modification in this scenario. An OOP design would have been identical (the data table was intended to be modified "on the fly", although we never needed that capability and thus never implemented it - the data is just an Ada aggregate currently), with the exception that the case statement would be replaced by a registration routine that gathered all of the units together. I fail to see how that would have improved anything about the design. It would, however, have provided an easier way to make the design far more complex (and less maintainable, IMHO), by adding interfaces to support dubious capabilities (and thus changing the behavior of the core web server), rather than funneling everything through the interface. Randy.