Well, most of the data we deal with is write once, read many, so yes there is a huge advantage to reading in the objects and effectively having them detached and held as objects only in memory. As a result, all of the usual transaction and semaphor stuff is out, once the objects are queried out of squeryl, they are as fast as any plain old object. If you want to do an update, you issue it through the update DSL and get the new fresh object out. You could get the same with JDBC, but it's less code with Squeryl's DSL.
As for immutable objects, surely at this stage of the game their value is not in dispute (is it, really?). I would not trust a multi-threaded system with shared mutable state no matter how good I thought I was with synchronizing threads. If Brian Goetz, Doug Lea and Guy Steele don't trust themselves, then I would say the rest of us are foolish to think we can do any better. I have also noticed no performance loss from the number of short lived immutable, small objects created - the garbage collector works more quickly on young objects, and performance of running code is one concern I have not had at all with Scala. There is a warm and fuzzy feeling too - I highly recommend it. I even have vars show up as red in my IDE in Scala, as a little reminder that I should not be using them (other than in very contained minimal scopes). In short, yes, it makes a real difference to performance. Using MongoDB with Scala does even more so. As for readability, case classes are a slam dunk for code readability. All values are immutable by default in those. Also the functional approach adds a lot to readability in my opinion - I would rather see a short function that transforms data represented by one case class into another case class, than a whole bunch of if statements, loops and mutable variables changing stuff in place. Makes it a lot easier to test as well. My functions in Scala rarely get to more than 10 lines in length, many are just one. Option is another profound improvement. I didn't get it at first, but the use of option as an alternative to in-line if statements adding or not adding things to a collection is far easier. I also haven't had a null pointer exception in close to a year now from any of my projects. Dick On Jun 15, 12:27 pm, Cédric Beust ♔ <ced...@beust.com> wrote: > Hi Dick, > > On Wed, Jun 15, 2011 at 10:28 AM, Dick Wall <dickw...@gmail.com> wrote: > > This does take a little getting used to, the "new" way often involves > > making a database update through a DSL expression (like a SQL update > > statement, which leaves the original object intact and just changes > > the data in the database), and then re-querying the object to get it > > in its new state, rather than just updating fields and saving the new > > object. > > I'm curious: do you get any concrete advantage from this, other than the > fuzzy feeling that you are using immutable objects? > > Specifically, I'm wondering about the impact of such an approach in terms of > performance and code readability. > > -- > Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
