Comments on: A Groovy Gotcha: list#flatten with a map/pseudobean inside http://enfranchisedmind.com/blog/posts/groovy-list-flatten/ programming, politics, & other religious issues Wed, 08 Feb 2012 14:16:00 +0000 hourly 1 By: Enfranchised Mind » Twitter and Blogging http://enfranchisedmind.com/blog/posts/groovy-list-flatten/#comment-33390 Enfranchised Mind » Twitter and Blogging Fri, 20 Jun 2008 05:23:36 +0000 http://enfranchisedmind.com/blog/?p=656#comment-33390 [...] leaves just the more thorough blog posts on topics (like Groovy’s list#flatten and the status of Ruby’s libxml) and reasonably significant announcements (like presentations [...] [...] leaves just the more thorough blog posts on topics (like Groovy’s list#flatten and the status of Ruby’s libxml) and reasonably significant announcements (like presentations [...]

]]> By: Robert Fischer http://enfranchisedmind.com/blog/posts/groovy-list-flatten/#comment-33375 Robert Fischer Tue, 17 Jun 2008 02:23:47 +0000 http://enfranchisedmind.com/blog/?p=656#comment-33375 Given the preponderance of bean structures in Java, I'm actually a fan of the ability to drop maps in and just move on with life: it's very similar to Perl's old solution, and OCaml's records. The problem is solved if maps are left unadulterated by list#flatten, so that's what we've gone for. I'm not sure who originally decided that excising values and flattening those -- nobody on the Groovy developer list has fessed up to it or come to the defense of that implementation. Given the preponderance of bean structures in Java, I’m actually a fan of the ability to drop maps in and just move on with life: it’s very similar to Perl’s old solution, and OCaml’s records.

The problem is solved if maps are left unadulterated by list#flatten, so that’s what we’ve gone for. I’m not sure who originally decided that excising values and flattening those — nobody on the Groovy developer list has fessed up to it or come to the defense of that implementation.

]]> By: bhurt http://enfranchisedmind.com/blog/posts/groovy-list-flatten/#comment-33374 bhurt Mon, 16 Jun 2008 22:42:10 +0000 http://enfranchisedmind.com/blog/?p=656#comment-33374 There's a wonderfull concept from Neal Stephenson's "In the Beginning was the Command Line" of Metaphor Shear. He was talking about GUIs- how suddenly you discover that your word processor isn't a typewriter, for example- but it applies here. You had a metaphor that you could treat a map like an object, and it worked really great- right up to the point where it didn't. This is why I'm very suspicious of things masquerading as other things. I'm not talking about data abstraction layers here, for example hiding a map inside some other object. No, I'm talking about maps pretending to be objects, lists pretending to be arrays, etc. There isn't a problem saying "this isn't a map, this is a foo", because there's no preconceived notion of what a foo is, or how it behaves. But trying to say "this isn't a map, it's a list!" tends to lead to tears and recriminations. The Liskov substitution principle applies- "is a" relationships are do or do not, there is no try. And your language is doing you no favors giving you an "almost is a" relationship. There’s a wonderfull concept from Neal Stephenson’s “In the Beginning was the Command Line” of Metaphor Shear. He was talking about GUIs- how suddenly you discover that your word processor isn’t a typewriter, for example- but it applies here. You had a metaphor that you could treat a map like an object, and it worked really great- right up to the point where it didn’t.

This is why I’m very suspicious of things masquerading as other things. I’m not talking about data abstraction layers here, for example hiding a map inside some other object. No, I’m talking about maps pretending to be objects, lists pretending to be arrays, etc. There isn’t a problem saying “this isn’t a map, this is a foo”, because there’s no preconceived notion of what a foo is, or how it behaves. But trying to say “this isn’t a map, it’s a list!” tends to lead to tears and recriminations.

The Liskov substitution principle applies- “is a” relationships are do or do not, there is no try. And your language is doing you no favors giving you an “almost is a” relationship.

]]>