Re: [The Java Posse] Stephen Colebourne on Scala (ouch!)

The bug of which you speak is nested extractors generate exponential-space bytecode https://issues.scala-lang.org/browse/SI-1133, and is being worked on. Matthew Farwell. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To view this discussi

Re: [The Java Posse] What is the most technically impressive Android game/app and why ?!?

On Thu, 24 Nov 2011 05:58:37 +0100, mP wrote: Ive been looking at the market place and noticed most games are rather simplistic, mostly bright colours and lots of sprites. This seems to remind me of the Amiga with 3D etc to follow with modern PCs. ... Correct. That's what the market asks for,

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

On Wed, 23 Nov 2011 23:38:07 +0100, Martijn Verburg wrote: Hi Dick, I like your Courage analogy. My Diabolical Developer talk at Devoxx was very much in the same vein, although hidden behind a wall of UK/NZ irony and sarcasm. Thinking for yourself and not blindly trusting the 'Giants' in our

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

I guess I missed the point in my (rather terse) example. What I was demonstrating is that the expression doesn't just change the contents of the collection, but also the type of the collection itself. For example: *val bitSet = BitSet(1,2,3) //a BitSet can only hold integers, it subclasses Set[I

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

Very nice examples but perhaps better to lose the reference to "LSP" or make it clearer? If the next line after setting res2 is: assert(res2.isInstanceOf[BitSet]) then I don't quite get substitutable behavior if I am expecting a BitSet. LSP within certain bounds for sure but not blanket LSP. Also,

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

What LSP essentially states is that because a BitSet is-a Set, then it should be transparently usable everywhere that a Set is valid. One possible operation on a Set[T] is to convert all members to strings, yielding a Set[String]. A naive implementation of BitSet would only support a map(fn: Int

Re: [The Java Posse] overtime and job hunt

My current client has the same restriction on consultants, though I can take the code home on the laptop they provided. I don't think it's always about security, but often about the battle between employees and contractors. In the original context I thought we were talking about employment rath

[The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

Q.E.D. http://blog.joda.org/2011/11/scala-ejb-2-feedback.html -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/al93I5bVmtEJ. To post to this group, send emai

[The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

Hi Dick, Just wanted to say publicly that I checked both the "pending" and "spam" sections of Blogger's comments when Cedric mentioned it to me yesterday and I didn't find any post from you. What happened? Sadly, I've no idea. I can happily say that I've never censored an opinion on my blog and the

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

"You know who else compared Scala with EJB? Hitler. Runar Oli tweet (which I took in good humour)" LOL -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giud...@tidalwave.it http://tidalwave.it - http://fabriziogiudici.it -- Yo

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

On Thu, Nov 24, 2011 at 1:28 AM, Kevin Wright wrote: > > This is all 100% safe and statically typed, and is made possible by the > "scary" CanBuildFrom implicit parameter that Stephen mention in his article. > > I don't believe that Fantom can do this > It depends on what you mean by "this", but

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

Hi, No, sorry, but you still miss the point. The thing Kevin tries to explain is that the collection methods are far more flexible, because they can select the “next best available” type if the “best available” type just doesn't exist. This occurs in “the real world” (BitSet, String, ...) and t

Re: [The Java Posse] overtime and job hunt

I was just saying that it was the reason I heard all the time. I really think it has to do with management style. Newer and more progressive companies are more flexible in this regard. Older companies tend to stick with tradition or see working at home as a benefit. There are places where security

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

I guess the elephant in the room is mutability. Whereas the Scala code I quoted will take an immutable map and result in an immutable map, your fantom equivalent is obviously relying on externally visible mutability to provide equivalent behaviour. I certainly wouldn't feel comfortable passing th

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

Kevin, you know that people do manage with mutable values as if they were immutable pretty often. I actually only found out that java.util.Date was mutable recently (or I forgot at some point) and have been treating it as immutable all these years. Perhaps there's someone maintaining some code I

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

Mutable Dates are actually the lesser evil here, it's when you try to use the same instance SimpleDateParser on multiple simultaneous threads that you feel the real pain. It certainly looks like something you could think of as a pure function from String => Date, but uses non-thread-safe internall

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

On Thu, Nov 24, 2011 at 3:42 PM, Kevin Wright 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

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

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 Beu

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

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, 2

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

That's encouraging, not enforcing. Nothing stops you from importing the mutable map type. All you showed is that your code sample uses an immutable type. On Thu, Nov 24, 2011 at 9:50 PM, Kevin Wright wrote: > C'mon! > 1. Open a fresh scala REPL. No imports, no other lines of code, just a clean

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

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 keywo

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

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 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

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

On Thu, Nov 24, 2011 at 5:05 PM, Ricky Clarkson wrote: > That's encouraging, not enforcing. Nothing stops you from importing > the mutable map type. > Nor using "var" instead of "val". -- Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse"

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

On Thu, Nov 24, 2011 at 5:11 PM, Kevin Wright wrote: > Otherwise, it's semantics. method params are immutable Same as Java. > unless, the standard keyword for values is "val" And "var" for variables, with Scala not encouraging either over the other. > (equivalent to final in Java), and co

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

Method parameters are not immutable in Java without the final keyword. 2011/11/24 Cédric Beust ♔ : > > > On Thu, Nov 24, 2011 at 5:11 PM, Kevin Wright > wrote: >> >> Otherwise, it's semantics.  method params are immutable > > Same as Java. > >> >> unless, the standard keyword for values is "val"

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

Fun exercise - someone who knows Scala can probably do better - of course you could hide all this away in a library and make it really easy if you wanted: val m = Map(1->"a",2->"b",3->"c")val field = m(1).getClass.getDeclaredField("value")field.setAccessible(true)val mods = field.getClass.getDecla

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

Fun exercise: val m = Map(1->"a",2->"b",3->"c") val field = m(1).getClass.getDeclaredField("value") field.setAccessible(true) val mods = field.getClass.getDeclaredField("modifiers") mods.setAccessible(true) mods.setInt(field, field.getModifiers & ~java.lang.reflect.Modifier.FINAL) field.set(

Re: [The Java Posse] Re: Stephen Colebourne on Scala (ouch!)

Sorry about the formatting glitches, trying again: val m = Map(1->"a",2->"b",3->"c") val field = m(1).getClass.getDeclaredField("value") field.setAccessible(true) val mods = field.getClass.getDeclaredField("modifiers") mods.setAccessible(true) mods.setInt(field, field.getModifiers & ~java.lang.ref