Optional arguments in Scala

I couldn't find much on the web with this search and it took me maybe 15 min to figure it out, so here's the low down on using optional arguments in Scala. There's a description in section 8.8 in the Programming in Scala book - they call them "repeated parameters".

Using this notation you can overload Java methods with optional parms as well as pass them over to a "super." method (which was what I needed to do):

def takesOptionalArgs (x:String*) = {
   println ("Scala println: ", x.mkString(" "))
   java.lang.System.out.printf ("Java printf: %s %s %s", x:_*)
}

This special syntax instructs the compiler to pass the x array elements individually, not as an array!

Cheers.

[later edit] P.S. Note that there's an outstanding defect for overloading java vararg methods - it currently doesn't work: https://lampsvn.epfl.ch/trac/scala/ticket/1459

Agile Architecture talk from Coplien

For a nice glimpse at the future of programming as it evolves, I strongly recommend this talk from my favorite architecture guy: Coplien. Prerequisites: get a beer, slippers and a robe, the conclusion is not light reading!

http://blog.jaoo.dk/2009/03/04/handling-architecture-in-the-agile-world/

Some of the things that deserve emphasis:

• The need that the application’s own model matches the model the users have in their head, i.e. the “view of the world” is obvious, but, unfortunately, it is not obvious to many…


• Architecture is the essence of structure (the form), not the structure itself.

A good agile/lean architecture:

• supports change


• Supports user interaction


• Lowers discovery costs, rework

Other memorables:

• Habitable code – code where the designer could choose to live. Do you like your code? Would you live with it?
  


• Refactoring is bad! We want to avoid re-work…you need a system view, not code–as-you-think!
  


• The long forgotten purpose of OO is to capture the model from the user’s mind, not create toys for developers!
  


• (Razie says hmm): Do object diagrams instead of class diagrams – users think in terms of instances, not abstract classes.
  


• The GUI is not something between the GUI and the model, is a tool allowing the user to mess with the model! Kent Beck said “you can’t hide a bad architecture behind a good GUI”.
  


• (Razie says hmm): Requirements are the LAST thing you look at when doing architecture!
  


• Need architecture upfront, code just-in-time!
  


• Java is a TOY language.
  


• Scala’s got traits, baby!
  

This is the brief follow up: http://blog.jaoo.dk/2008/12/20/jaoo-video-2008-james-o-coplien/

• Peter Coad’s now a pilot, but his role-based color modeling should’ve taken off!