Re: Parser interface design

[Natasha Kerensikova <lithiumcat@gmail.com>]

Hello,

On 2011-04-06, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> 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