[xsd-users] Visitor pattern automatically generated/ and/or included

Boris Kolpackov boris at codesynthesis.com
Wed Jul 22 14:26:25 EDT 2009


Hi Christopher,

Christopher Fuhrman <christopher.fuhrman at etsmtl.ca> writes:

> Automatically generated object structures seem *very* likely to change.

Hm, I don't know. If the schema is mature and stable, I don't see a 
reason why the object structure has to change very often.


> The original question mentions getting an automatically generated traverser,
> which is similar to two variants of Visitor mentioned in GoF: traversing
> logic in an Iterator or in the Composite structure. It might make sense in a
> code-generation scenario to generate this traversing logic, but without
> using a Visitor that knows about all elements. 

There are a number of ways to improve the Visitor design so that there
is no central Visitor class. For example, in the XSD compiler itself
we use a traversal technique which has a separate traverser class for
each object model type. These traversers can then be collected at 
runtime and dispatched on a object. The main drawback of such
approaches is the speed since they rely on (custom) RTTI and dynamic
type casting. The big advantage of the original visitor design is that
it costs just two virtual function calls. 


> Maybe it would make sense to hand-code a Visitor in this case once 
> (if?) the data structure is stable?

The problem is with implementing the accept() functions. They need
to be part of the object model and the only two ways to achieve this
without modifying the code generator is to modify the generated code
or customize each type in the object model.

I agree though that providing a hand-written Visitor interface is
probably not a big deal in this case.

Boris




More information about the xsd-users mailing list