Then in your head there must be more distance between 'enforce' and 'force' than in mine.
On Thu, Nov 24, 2011 at 10:11 PM, Kevin Wright <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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 ♔ <[email protected]> >>>> >>>> On Thu, Nov 24, 2011 at 3:42 PM, Kevin Wright <[email protected]> >>>> wrote: >>>>> >>>>> it embraces the same ideals of immutability that he once championed >>>> >>>> We already went through this, 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 [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. > > > > -- > Kevin Wright > mail: [email protected] > gtalk / msn : [email protected] > quora: http://www.quora.com/Kevin-Wright > google+: http://gplus.to/thecoda > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
