[
Lists Home |
Date Index |
Thread Index
]
james anderson <james.anderson@setf.de> wrote:
| Arjun Ray wrote:
|> 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.
Right. That's the idea in interface Element { } - the app decides what
model to build at any point.
|> 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?
Yes, they tag team (or rather, they can). Recursive descent is designed
to mix match-token and build-model functionality, doesn't it?
|> 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.
Agreed, I was saying the same thing but didn't express myself clearly
enough. The negation on "both" also applied to "either".
|
