Comments on: Java’s final modifier is backwards http://jakeherringbone.com/2008/12/javas-final-modifier/ My thoughts on life, work, coding, and stuff I like. Tue, 09 Mar 2010 18:51:47 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Assert, Validate, Precondition | Jake Herringbone http://jakeherringbone.com/2008/12/javas-final-modifier/comment-page-1/#comment-65 Assert, Validate, Precondition | Jake Herringbone Sat, 17 Jan 2009 20:26:31 +0000 http://jakeherringbone.com/?p=127#comment-65 [...] Immutability - final should be the default [...] [...] Immutability – final should be the default [...]

]]> By: Alex http://jakeherringbone.com/2008/12/javas-final-modifier/comment-page-1/#comment-50 Alex Fri, 05 Dec 2008 21:32:22 +0000 http://jakeherringbone.com/?p=127#comment-50 It turns out that there was a bug created in the JCP to make use of the const keyword - it's currently a ghost in Java, as it has no semantic meaning. The bug description includes a thorough treatment of how the const keyword would support immutability. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070 It turns out that there was a bug created in the JCP to make use of the const keyword – it’s currently a ghost in Java, as it has no semantic meaning. The bug description includes a thorough treatment of how the const keyword would support immutability.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070

]]> By: gabe http://jakeherringbone.com/2008/12/javas-final-modifier/comment-page-1/#comment-46 gabe Thu, 04 Dec 2008 08:14:02 +0000 http://jakeherringbone.com/?p=127#comment-46 I think Java collections should have had immutable base classes with mutable subclasses, like List/MutableList (like how Cocoa does NSArray/NSMutableArray). I also really dig the var, val syntax where you define the type after the name, like: var foo:Bar; or in cases where you want to be dynamic and immutable: val foo = new Bar(); (or var foo:* = new Bar(). Thats where languages like Actionscript have a big win. It also becomes easier to add modifiers like val after the fact. I wonder if, much like how Actionscript supports static or dynamic typing (and ability to turn it on or off at compile or runtime), you could turn on the enforcing of immutable references in the same way. Then you would have a language that can be either static/dynamic and mutable/immutable. And it would be fun to use this language to build a web framework (dynamic, mutable) or a highly concurrent message bus (static, immutable). Kind of like polygot programming but without the need for all the different languages and runtime integration. I think Java collections should have had immutable base classes with mutable subclasses, like List/MutableList (like how Cocoa does NSArray/NSMutableArray). I also really dig the var, val syntax where you define the type after the name, like: var foo:Bar; or in cases where you want to be dynamic and immutable: val foo = new Bar(); (or var foo:* = new Bar(). Thats where languages like Actionscript have a big win. It also becomes easier to add modifiers like val after the fact.

I wonder if, much like how Actionscript supports static or dynamic typing (and ability to turn it on or off at compile or runtime), you could turn on the enforcing of immutable references in the same way. Then you would have a language that can be either static/dynamic and mutable/immutable. And it would be fun to use this language to build a web framework (dynamic, mutable) or a highly concurrent message bus (static, immutable). Kind of like polygot programming but without the need for all the different languages and runtime integration.

]]>