Puzzler 17

[dgruntz]

As announced. This puzzler covers twin assignments where two variables are initialized in one go (comparable to x = y = in Java or C).

[demobox]

Good to go for me. @nermin ?

[nermin]

Wow, I didn't even know pattern binder existed! Good to go.

[demobox]

I'm pretty sure you did...

val (x, y) = (1, 2)

? ;-)

[nermin]

Ah, yes, but not in a form of x@p.

[demobox]

Good to see that the puzzlers are keeping up their educational value! ;-)

[demobox]

http://scalapuzzlers.com/#pzzlr-017 ;-)

[demobox]

After showing this puzzler yesterday, I'm wondering whether we should substitute eq for == as the comparison:

println(x1 eq x2)
println(y1 eq y2)

If we consider the knowledge that == on "plain" objects is reference equality then I'm fine with keeping it, but if we just want people to think about how many objects are being created here I think eq would be clearer.

@dgruntz Thoughts?

[dgruntz]

For me it was (and is) clear, that if class C is defined that way, then method == performs a simple reference comparison, so it was not that knowledge I wanted to test here. In order to make the puzzle more concise, I support to replace the equality comparison with an explicit reference comparison. I have submitted #60.

[demobox]

For me it was (and is) clear, that if class C is defined that way, then method == performs a simple reference comparison

I've presented the puzzler a few more times since then (at Devoxx just now - everybody seems to have a good time ;-)) and the feedback is indeed that == is clear enough. So I don't think we need the pull request after all, but thanks for submitting, of course.

Good to hear from you! ;-)