Talk:Case Study of Writing the Extensible Visitor Pattern

From APIDesign

Done: 3bfa995fae68

I liked this section, too. Practical, example-based ways of applying the concept learned in the book. Awesome.

I'd almost recommend that this and the previous section should be in their own part of the book. "Part IV: Experiences" or something.

Paragraph 2: "in the tool apt" doesn't make sense. If "apt" is the name of the tool, it needs to be set apart in quotes or in typeface.

"traversing hierarchies of heterogeneous data structures" (note the spelling of heterogeneous) is quite a chunk of text. Any way to make that a little less haughty-sounding?

--Dmkoelle 02:47, 23 April 2008 (UTC)

"would keep all kinds of compatibility, see expr, based on generics": what is "expr"? Looks like a link is missing.

Why are most of the classes in the visitor examples static?

In the visitor pattern, it is common for the method in the element classes (Plus, etc.) which takes a visitor instance to be named accept, not visit.

The "Old visitor used on new exceptions" message in the abstract Visitor doesn't make sense to me, perhaps "new elements" is what you meant.

Common Java code conventions advice against underscores in identifiers. Moreover, you talk about "Valid10" and "Visitor70" in the text. Please make this consistent, ideally by removing the underscores.

"exception subtype" should probably be "element subtype".

Perhaps I'm just missing something, but we fact that visitMinus visits the children elements by default looks wrong to me. The visitor pattern describes the visitor as an interface with no default behavior. The actual behavior is implemented by the visitor implementation. But here, you have made an arbitrary choice for the behavior (what if I want to visit the numbers in postorder?), and worse, only for a part of the tree.

"the client visitor that just called the method" looks unclear. How about "the Visitor which was passed to Expression.visit"?

--AndreiBadea 12:44, 23 April 2008 (UTC)

This is my favorite chapter. You're applying the techniques and advice of your style of api design to a well-known design pattern and coming up with something much better. And you're explaining it in a clear, well-delineated manner. Bravo!

Andrei, think of the visitMinus example in a different context, like a validating SAX parser. This is like having a flag that tells the parser whether to quit when it finds an unknown tag, or whether to visit the child elements anyway.

--Richunger 05:19, 26 April 2008 (UTC)

I believe I stated this before, but 'cnt' is probably not a great variable name given its similarity to a rude word in English.

--TomWheeler Wed Apr 23 20:38:48 CDT 2008

Done: 499a5aa967f6

I forget if you introduced the term "non-monotonic" in an earlier section. I don't understand what it means here. A more clearly understandable term might be more appropriate.

--Dmkoelle 02:49, 23 April 2008 (UTC)

• Monotonic functions are either ascending or descending ones.

I understand what you mean. Non-monotonic is okay, but perhaps "purely additive" is more colloquial. --Richunger 05:22, 26 April 2008 (UTC)

Done: 63380b03e629

"triple" not "tripple" --Dmkoelle 02:51, 23 April 2008 (UTC)

Done: 47a774813dc9

"sugar" not "suggar" --Dmkoelle 02:51, 23 April 2008 (UTC)