Lists Home |
Date Index |
Arjun Ray wrote:
> james anderson <firstname.lastname@example.org> wrote:
> | in the case of a pull parser, calls like currContent.newChild, below,
> | produce instances which are eventually passed back to the application,
> | while in a push parser they pass control into the application. there
> | is little difference between the two.
> I'm probably misunderstanding what you're saying, but one big difference
> would seem to be that the definition of the instance is determined by the
> parser system with pull and by the application with push.
unless the parser always works with a construction context, for which application provides the initial value. in that case, the context is in the position to
instantiate model nodes.
> If you're
> saying that access to the parser (to pull event notifications) could be
> tag-teamed - on a call stack - between instance builders and content
> handlers, I'd agree: this is just the classic recursive descent pattern.
is it? does "classic recursive descent" pass both a control instance and a model instance?
> | nb. it is better for the interface and logic to distinguish between the
> | construction context and the constructed instance and to permit the
> | application the opportunity to decide whether they coincide.
> Yes, that's why I termed the example "cheesy". The same class need not
> implement both Element and Content interfaces. The point of the pattern is
> the ability to separate them.
more general than that. the same class need not implement both the model and control interface. it applies to whatever is to be parsed, not just elements.