Friday, November 21, 2003

What would be your favourite JVM enhancements? This came up in various ApacheCon chats I had recently. I'm not too bothered about templates in 1.5, especially since the new for loop syntax makes them mostly unnecessary (iteration is the main itch that templates scratch for Java developers IMHO). Top of my list would be clean continuations support; so building web applications or distributed systems (especially workflow related) would be really simple while keeping a normal procedural / imperative style. Anyone who's not grokked continuations should look at seaside or the stuff the cocoon folks are doing with flowscript. There are a couple of implementations for Java. (I confess to not having looked too deep at brakes yet) but they usually are knobbled a bit or add a reasonable amount of overhead to the JVM. Surely it wouldn't be too hard to add support for this to the JVM? Proably next on my list (or maybe in front of it) would be the cardinality changes that are described in Xen. I guess you could use templates for that, but its not as clean or elegant. The Xen approach is way elegant. 4:06:26 PM    comment []

Why does Matz not like passing local variables into closures in Ruby? Matz recently mentioned this in a talk on Ruby 2 that he regrets the feature in Ruby of being able to change an outer local variable inside a closure - I've tried googling for an explaination and not come up with anything yet. I'm wondering if any Ruby gurus know the answer? I'm wondering if Matz just means that local variables can be passed into a closure/block but that changing the value inside the block should not be reflected outside of the closure? I'm pondering about doing something similar in Groovy; allowing variables to be passed into a closure as parameters - though I'm wondering if we should go the whole hog so that if variables are changed inside the closure that they are also changed in the outer scope (which could cause a race condition / multi-threaded problem). Since Matz seems to regret this decision, I'm tempted to follow suite though I'd like to see the reasoning behind it first. If you can just pass variables into a closure then the user could always use some kind of holder object (which could have thread synchronization inside it if required etc.) to allow variables to be changed inside a closure & reflected back. e.g. # pass in read only variable foo = 2 closure = { assert foo == 2; foo = 3 } closure.call() assert foo.value == 2 # allow mutable variable foo = new Holder() foo.value = 2 closure = { assert foo.value == 2; foo.value = 3 } closure.call() assert foo.value == 3 Thoughts? Update: actually I think I totally misunderstood the slides - since crossing timezones my brain's not quite caught up yet :). Thanks to Matt Foemmel on groovy irc for correcting my misunderstandings. This slide makes it a bit more clear. I think Matz is arguing that all variables declared inside a closure should be available to the outer block as local variables. I think I got it now :) 1:17:31 PM    comment []

codeja vu I love Geir's codejar vu post. That "hey wait a minute, haven't I implemented this once already" thought is quite common, especially if you've been writing java code for a while. 11:57:54 AM    comment []