Thursday, April 14, 2011 8:43 PM | rahel luethy | 3 comment(s)
As promised, here is the second post in my haphazardly thrown together Scala series. Over the past few days I have read some chapters in Odersky's Programming in Scala, and most importantly, I have written my first ~100 lines of code (a basic Minesweeper app with a simple Swing UI). It's been a lot of fun, and I am still very enthusiastic about many new concepts & constructs. When coding, the biggest challenge is to not fall back to imperative Java style, but really use the functional concepts wherever applicable. I am probably still not radical enough, but for the time being, here is my take on revealing non-mined cells:
In summary: 1 usage of => (and even a recursion ;-)).
12:11 AM | kyb said...
For pure functional you should avoid mutable state too. Perhaps return a whole new board state after each user interaction?
8:55 AM | rahel luethy said...
Thanks for pointing that out! I was aware of it -- the fact that reveal() doesn't return a result is a clear smell...
Addressing that will be the goal of my next refactoring. However, it is somehow clashing with my "Javaesque" idea of MVC: What is Scala's take on propagating model changes to the UI? With the mutable "resolved" property, it was quite straightforward. On a similar note: Why does the Publisher trait belong to the swing package? Wouldn't it be desirable to have observability independent from the GUI framework? Still a lot to learn, obviously ;-)
7:14 PM | kyb said...
I'm struggling with this stuff too. MVC is essentially an OO pattern, and lots of OO patterns use mutable state, so I'm not sure if there is a natural functional version.
It seems that most functional UI libraries are scenegraph based (i.e. not really very much like swing at all), so perhaps we're forced into using scala's OO side simply by the fact we're targetting swing.
