“If i’d have to chose between Tuple2[Bar, Baz] and case class Foo(bar:Int, baz:Int) i’d take the tuple variant without hesitation, all the time.”

The rest of the post was meandering ramblings anyway.

Using tuples instead of proper domain classes isn’t that much of a problem – as long as your tuple members are proper domain types and not just raw primitives.

If i’d have a choice between Pair[Bar, Baz] than class Foo(bar:Int, baz:Int) i’d take the tuple without hesitation.

Most value-carrier classes are defined pretty well by the types of their members, provided the member types are meaningful. Slapping a name tag to that composition of member types is only a convenience (or waste of time, some might argue), as long as that specific composition of member types is unique in that there is no need to partition the set of instances of that specific composition of member types into multiple classes.

It even happened on this blog: http://codemonkeyism.com/never-never-never-use-string-in-java-or-at-least-less-often/

Thinking further along this line i think it really is sad that Scala does not provide a way to specialize from final classes (or maybe that possibility exists and i just don’t know about it, which would give the sadness a more local scope). Of course subtyping from final types would have to be limited to “straight” subclassing (not adding or changing structure or behaviour), but it would be just so very handy for semantic types like FirstName or LastName. It wouldn’t even be a big loss if those “straight subtypes” would fall victim to erasure, as their main utility would be at compile time (and this limitation could make it possible to keep the instances-of-primitive-classes-are-primitives-at-runtime magic in place for subtypes of, say, Int, which would certainly be of biggest importance).

I’m sure Scala has some very nice tricks to emulate subtyping from from finals (just think of what RichString does), but that would open the gates for structural/behavioral changes as well which might not be so good. Also, there is little chance for transparent suptyped primitives that way.

Also, FWIW, I wrote a blog post deconstructing how the “map literal” works, wrt to ArrowAssoc and Tuples, for anyone interested:

http://www.naildrivin5.com/blog/2009/11/12/deconstructing-scala-map-literal.html

http://www.naildrivin5.com/blog/2009/11/24/scalas-map-literal-as-a-prezi.html

Also, I was wrong. It’s connascence of position. Here’s Jim Weirich’s definition: http://onestepback.org/articles/connascence/conposition.html

I’d never heard of connascence until Jim’s presentation at the Software Craftsmanship NA conference in August.

Good stuff. Thanks.

in your examples above, it really isn’t ever clear what those numbers actually represent. a lot nicer to make a Vector2 class, or a ReturnValues class or something, to actually represent what each of those numbers mean.

This is a form of execution connascence, and that bothers me.

Didn’t know – nice.

http://www.scala-lang.org/docu/files/api/scala/Predef$object.html#any2ArrowAssoc%28A%29

any2ArrowAssoc wraps a in a new ArrowAssoc object, and then ArrowAssoc’s -> method returns Tuple2(a,b). Pretty slick!

ArrowAssoc also has a → method which should render as a Unicode arrow, which is interesting.

http://www.askoxford.com/asktheexperts/faq/aboutgrammar/apostrophe

Keep up the excellent writing!