6 ms·
The gang of four book predates Java the language. FYI. The book's written in Smalltalk.
by jbooth 13y ago
The gang of four book predates Java the language. FYI. The book's written in Smalltalk.
- loup-vaillant 13y agoNow that is a surprise. Lemme check… https://en.wikipedia.org/wiki/Design_Patterns https://en.wikipedia.org/wiki/Design_Patterns Indeed. Written in 1994, and includes examples in Smaltalk… and C++. Now I know why it didn't rely on first class functions. It wasn't written in Smaltalk. It was written in the intersection of Smaltalk and C++. Sounds like Java, even though it didn't exit yet. Come to think of it, I wonder if they didn't have hints about this upcoming language from Sun. Java came out in 1995, but was in the works since 1991… So my point stands. If it were really written in Smaltalk, it wouldn't have needed insanities such as the Visitor pattern to work around the lack of closures. It would have used Smaltalk Blocks directly.
- jbooth 13y agoWell, I'm glad you've concluded that you're still right.
- loup-vaillant 13y agoLose the sarcasm, please. If you still believe I'm wrong despite my documented arguments, I suggest you put forth documented counter-arguments. It will have two benefits: 1: You may convince me. I'm serious. I do not anticipate any strong counter arguments, but if they come, I will listen. (I did listen to your first argument. It troubled me, really, I was certain the book was written in Java. So I checked.) 2: You may show the other readers the error of my ways. Since my arguments are documented and relatively articulate, they will likely sway anyone who isn't committed to a particular position. You wouldn't want me to put false ideas in their heads.
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]
- seanmcdirmid 13y agoThe book really was written with Smalltalk in mind with the C++ examples added for marketing reasons. If you want to go argue with Ralph Johnson (aka the god of Smalltalk) about it, be my guest.
- loup-vaillant 13y agoActually, I'm starting to want to read this book, if only to see how far down the rabbit hole goes. Depending on what I find, I may want to demolish it. I don't care if the authors are gods, this glimpse of their work does not look good.
- seanmcdirmid 13y agoThis interview with 3 of the gang of 4 (Vlissides unfortunately passed away a few years ago) might help you get it: http://www.informit.com/articles/article.aspx?p=1404056 http://www.informit.com/articles/article.aspx?p=1404056
- twic 13y agoThe visitor pattern is about doing different things to objects based on their class. What would make it redundant would be multi-methods, or pattern matching, not blocks. Smalltalk doesn't have a good alternative to the visitor pattern.
- loup-vaillant 13y agoOkay, let's read https://en.wikipedia.org/wiki/Visitor_pattern https://en.wikipedia.org/wiki/Visitor_pattern Oh, my. This is even worse than I had thought. The motivating section makes me want to grab my closure hammer, especially the "reuse of iteration code" motivation. I don't know how I would handle it of the top of my head, but the way the Wikipedia article present it feels wrong. The Java example looks more explicit. Oh, crap. This is Bad, Wrong, Horrible design. Sure, now the compiler can help you not forget cases, but you're still on the wrong side of the Expression Problem: for every single subtype you add, you still need to add a case to each of your visitors. Is this the kind of price one has to pay for class hierarchies?
- hyperpape 13y agoWhy are you talking about Java? You obviously don't know much about it. I don't even say this to defend Java, because I don't like it. But you're apparently just repeating secondhand information about it.
- loup-vaillant 13y agoI wasn't referring to the Java code. I stopped at the UML diagram. It was horrible enough by itself. Just look at it: https://en.wikipedia.org/wiki/Visitor_pattern#Diagram https://en.wikipedia.org/wiki/Visitor_pattern#Diagram For each class, you basically need to write an "accept" method to call the visitor. Fine for now. But then, the visitor specializes depending on the type of the object! Couldn't we just inline the appropriate visit method directly at the call site? It would get rid of all the boilerplate introduced by the visitor pattern, without duplicating more code. It would still suck[1], but it would suck less. [1]: https://news.ycombinator.com/item?id=7589623 https://news.ycombinator.com/item?id=7589623