Serving the Quantitative Finance Community

 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

visitor design pattern

December 29th, 2015, 5:01 pm

QuoteOriginally posted by: quartzQuoteOriginally posted by: CuchulainnHad a quick look. Must say I don't like it.Me neither, but it's being referenced here and there and its pros are interesting, so maybe it shouldn't get so easily dismissed.Anyway what about the benchmarks (for what they're worth)? :-)hi quartz,I don't use OOP patterns so much anymore but we used them with much success in CAD, graphics and optical technology (holography) in several production systems. There is probably no compelling reasons to use it. Besides, you choose between Boost static_visitor and GOF Visitor.Here is how we did (1995)/do VisitorThings have moved on; in FP languages Visitor is a fold and it's free. QuoteCooperative Visitor technique provides the flexibility of Acyclic visitor with performance that approaches the Cyclic visitor. Cooperative Visitor provides advantages over standard visitor implementations by allowing configuration: the name of visit methods, the return type, the const-ness, the number of arguments. The ease of use approaches that of other Visitor implementations and libraries. The technique is standard C++ and is portable. This is fine, but do we want so much flexibility? More is less?
Last edited by Cuchulainn on December 28th, 2015, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

visitor design pattern

December 29th, 2015, 6:33 pm

quartz,Do you have a specific test case in mind?
 
User avatar
quartz
Posts: 3
Joined: June 28th, 2005, 12:33 pm

visitor design pattern

December 30th, 2015, 11:08 am

QuoteOriginally posted by: CuchulainnI don't use OOP patterns so much anymore but we used them with much success in CAD, graphics and optical technology (holography) in several production systems. There is probably no compelling reasons to use it. Besides, you choose between Boost static_visitor and GOF Visitor.We need it dynamic, using static_visitor dynamically requires some tricks including preprocessor stuff making it all more convoluted than a dynamic visitor, and GOF is brittle and insufficient.QuoteThings have moved on; in FP languages Visitor is a fold and it's free. Almost spot on ;-)QuoteQuoteCooperative Visitor technique provides the flexibility of Acyclic visitor with performance that approaches the Cyclic visitor. Cooperative Visitor provides advantages over standard visitor implementations by allowing configuration: the name of visit methods, the return type, the const-ness, the number of arguments. The ease of use approaches that of other Visitor implementations and libraries. The technique is standard C++ and is portable. This is fine, but do we want so much flexibility? More is less?In this case it's basic language features missing not bells&whistles, so yes, I need it all, but without the hassle of cooperative visitor possibly. Requirements already dictate flexibility so that's not a choice, but currently we do it in a convoluted fashion, a big ball of mud is growing, and I want that cleaned out. And ideally I'd like static and dynamic dispatch with a common interface as with virtual functions. Anyway acyclic visitor has too much overhead for restricted functionality, there's space for some arbitrage here...We have various use cases, but of course the classical one are actions on heterogeneous object hierarchies... which gets particularly interesting when objects are algos and things get reflexive (that's why we couldn't use virtual funcs even if we had the patience), but that's another story.Actually they're currently discussing a visitor in the c++std list, but the major guys somehow aren't participating and the current state seems pretty lame.
 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

visitor design pattern

December 30th, 2015, 12:16 pm

QuoteWe need it dynamic, using static_visitor dynamically requires some tricks including preprocessor stuff making it all more convoluted than a dynamic visitor, and GOF is brittle and insufficient.What are the objections to GOF Visitor? Can you quantify? What are you trying to do with Visitor?If you have a stable Data (Context) hierarchy then Visitor is OK IMO. Quoteusing static_visitor dynamically requires some tricks including preprocessor stuff For example? QuoteWe have various use cases, but of course the classical one are actions on heterogeneous object hierarchies... which gets particularly interesting when objects are algos and things get reflexive (that's why we couldn't use virtual funcs even if we had the patience), but that's another story.Depends on the size of algo + latency.And can you parallelise a Visitor!(?)
Last edited by Cuchulainn on December 29th, 2015, 11:00 pm, edited 1 time in total.
 
User avatar
quartz
Posts: 3
Joined: June 28th, 2005, 12:33 pm

visitor design pattern

December 30th, 2015, 4:20 pm

QuoteOriginally posted by: CuchulainnQuoteWe need it dynamic, using static_visitor dynamically requires some tricks including preprocessor stuff making it all more convoluted than a dynamic visitor, and GOF is brittle and insufficient.What are the objections to GOF Visitor? Can you quantify? What are you trying to do with Visitor?If you have a stable Data (Context) hierarchy then Visitor is OK IMO.GOFV is also half static (fixed type->method relations), cyclic, convoluted to avoid RTTI, lacks parameters, constness etc... and of course data types are stable until they aren't. There's a plethora of GOFV improvements around.QuoteQuoteusing static_visitor dynamically requires some tricks including preprocessor stuff For example?Oh well, if there'a better way I'm all ears. Haven't done it so I don't remember details; iirc metaprogramming can also be used... but I could dig out where that came from.QuoteDepends on the size of algo + latency.And can you parallelise a Visitor!(?)Sure. But sometimes a tiny subalgo acts often on small objects.
 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

visitor design pattern

December 30th, 2015, 6:26 pm

What about a redesign to eliminate Visitor altogether?And then work by breaking the application into independent components that send generic Commands to each other? Visitor are not needed.http://uosis.mif.vu.lt/~plukas/resource ... dfThinking out loud; what about bimap<DataThing, Command> But it is a kind of table lookup, so the algos should be heavyweight..C++11 has variadic parameters.. (see code) Solve one of your issues?// Basically what you need is multimethods...
Last edited by Cuchulainn on December 29th, 2015, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

visitor design pattern

December 31st, 2015, 9:17 am

What is a Visitor, really ? is it not a command or function applied to an object C? The function has a return type, using the public interface of C and has (variadic) arguments?The new function is not a member function in general. C# has extensions methods like this (but no polymorphism..)?