You can change everything with reflection, even the interned values for strings and boxed integers. This is a good one to hold in reserve for April fools day... If you're going to reflect then ALL bets are off :)
Otherwise, it's semantics. method params are immutable unless, the standard keyword for values is "val" (equivalent to final in Java), and collections in the standard library are immutable unless you explicitly import mutable variants. Yes, *of course* you can choose to use mutable collections or to use vars, this is why I say "encourages" immutability. If I were to claim that scala "forces" immutability, then the grounds for calling me out on this would be far, far stronger. On 25 November 2011 01:01, Takeshi Fukushima <takesh...@gmail.com> wrote: > how about reflection? > > I'm joking of course so more to the point: those seems to be examples of > how the library encourages you to use immutable data structures whereas > what Cedric seems to be implying is that the language itself doesn't (or > that is how i read his response anyway) > > On Thu, Nov 24, 2011 at 10:50 PM, Kevin Wright > <kev.lee.wri...@gmail.com>wrote: > >> C'mon! >> >> 1. Open a fresh scala REPL. No imports, no other lines of code, just a >> clean standard REPL >> 2. val m = Map(1->"a",2->"b",3->"c") >> 3. Your challenge, should you accept it, is to manipulate m in such a way >> as to change its value >> 3a. and no, creating a new m doesn't count >> >> >> 2011/11/25 Cédric Beust ♔ <ced...@beust.com> >> >>> >>> On Thu, Nov 24, 2011 at 3:42 PM, Kevin Wright >>> <kev.lee.wri...@gmail.com>wrote: >>> >>>> it embraces the same ideals of immutability that he once championed >>> >>> >>> We already went through >>> this<http://groups.google.com/group/javaposse/msg/ec7eb89d89bdcd17>, >>> Scala "the language" does very little to enforce immutability. Hardly more >>> than Java. >>> >>> -- >>> 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. >> > > > > -- > http://mapsdev.blogspot.com/ > Marcelo Takeshi Fukushima > > -- > 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. > -- Kevin Wright mail: kevin.wri...@scalatechnology.com gtalk / msn : kev.lee.wri...@gmail.com quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda <kev.lee.wri...@gmail.com> twitter: @thecoda vibe / skype: kev.lee.wright steam: kev_lee_wright "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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.
