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,50e705cdf2767cc6 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Parser interface design Date: Thu, 7 Apr 2011 19:14:33 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1p6q05xtgjspf.7qanu7wlynvi$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Thu, 7 Apr 2011 19:14:33 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="8993"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+1xgpvF3T5oafpGY0Q02rq" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:rtGpdxrHNjOTPYIUytw9gDIDpbk= Xref: g2news1.google.com comp.lang.ada:18709 Date: 2011-04-07T19:14:33+00:00 List-Id: Hello, On 2011-04-06, Dmitry A. Kazakov wrote: > On Wed, 6 Apr 2011 10:11:46 +0000 (UTC), Natasha Kerensikova wrote: > >> I thought the most idiomatic way of putting together a bunch of >> callbacks in Ada would be to use an Interface, and then rely on dynamic >> dispatch. > > It also can be an abstract base type with primitive operations defined > null. The advantage is that you can have a "null function" and non-null > implementations with a type, which you cannot with an interface. That's an interesting idea, however that prevents a renderer object from being based on another type, like Controlled or Limited_Controlled - unless I base the abstract type on them. The null function fact seems very interesting though. Is it possible to test externally whether a given dispatched function is null? I'm asking because in my C implementation, a NULL callback was a meant to communicate to the parser that the associated active character should no longer be considered active, thereby switching off that particular feature (which is very different from having a no-op callback). >> The approach using tagged types implementing an interface seems heavier. > > You should not try to pack everything onto one types hierarchy. The parser > and renderer should likely be two different hierarchies glued together > through a mix-in in a third object aggregating both implementation. Actually I don't understand why there would be a second or even a third object in there. Would you mind expanding? In the example I proposed, the only object was the parser, which is tagged in order to provide dynamic dispatching. That's what would be in the renderer package. The parser package would be only a procedure, to which the client hand over the flow control, and which uses the callbacks from the tagged instance provided by the client. I don't see how to get from this to something where the parser and/or the client has a tagged object. >> So what would be the best approach to interface a parser and a renderer? > > The parsers I implemented used primitive operations as sematic callbacks. That sound exactly like what I proposed, doesn't it? Natasha