|
|
| Line 1: |
Line 1: |
| - | '''Done: 3bfa995fae68'''
| + | Food for thought. |
| - | | + | |
| - | | + | |
| - | 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?
| + | |
| - | | + | |
| - | --[[User:Dmkoelle|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 (<tt>Plus</tt>, etc.) which takes a visitor instance to be named <tt>accept</tt>, not <tt>visit</tt>.
| + | |
| - | | + | |
| - | The "Old visitor used on new exceptions" message in the abstract <tt>Visitor</tt> 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 <tt>visitMinus</tt> 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 <tt>Visitor</tt> which was passed to <tt>Expression.visit</tt>"?
| + | |
| - | | + | |
| - | --[[User:AndreiBadea|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.
| + | |
| - | | + | |
| - | --[[User:Richunger|Richunger]] 05:19, 26 April 2008 (UTC)
| + | |
Follow
