[concurrency-interest] Immutable object conundrums
ben_manes at yahoo.com
Mon Jul 20 02:12:45 EDT 2009
If you design OO based on Alan Kay's definition then there usually isn't an impedance issue:
"I decided to leave out inheritance as a built-in feature until I understood it better... OOP to me means only messaging, local retention
and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are
possibly other systems in which this is possible, but I'm not aware of them." -- Alan Kay
You can often mix functional programming ideas with object-oriented ideas and leverage a bottom-up, responsibility-driven approach. It may only seem incompatible because Java is usually written in a top-down OO model.
From: Ashley Williams <ashpublic at mac.com>
To: concurrency-interest at cs.oswego.edu
Sent: Friday, July 17, 2009 2:36:15 PM
Subject: Re: [concurrency-interest] Immutable object conundrums
Thanks to the many responses, just wanted to add a few more thoughts to this
thread to help any other concurrency newbies following behind me.
At first I found it difficult to see how to adapt my code to use immutable objects.
No matter how I baked it, I found myself removing problematic state from my
previously mutable classes, which rendered the code paths that could be seen by
different threads as nothing more than functions.
Now in itself this isn't a problem but since I have long ago abandoned inheritance
and to some extent "is-a" style interfaces, then this additional removal of state
means that the only OO feature I have left is encapsulation, i.e. the grouping of
like-minded methods in the same compilation unit. And even OO can't claim this
Anyway to cut a long story short, if anybody else finds themselves with nagging
doubts about their long cherished OO practices, take a look at the following
URLs, In particular the superbly eloquent clojure link was a real eye opener to me:
It almost feels like I'm starting again from scratch.
On 1 Jul 2009, at 12:00, Ashley Williams wrote:
> Just looked at the Fences API and this is exactly what I was trying to allude to.
> In fact I would personally prefer to see the explicit use of Fences.preStoreFence()
> instead of relying on memory model guarantees through the use of final. It would
> be all too easy for a developer to come along and mistakenly remove the multi-purpose
> final keyword without appearing to break the code.
> Am I right in thinking most jvms would implement this by writing to main memory (writes) and
> evicting entries from local memory (reads)? Just wondering about any performance costs.
> So if one were to use both a final field modifier as well as a fence, would the jvm be
> clever enough not pay the for the happens-before guarantee twice over?
> On 30 Jun 2009, at 21:46, Doug Lea wrote:
>> Peter Veentjer wrote:
>>> PS: Do you have a reference to the other concurrency features that are
>>> going to be added (apart from the fences and the fork/join
>>> functionality) to Java 7?
>> Definitely planned classes are in package jsr166y --
>> ForkJoin, Phasers, TransferQueue, ThreadLocalRandom. See
>> Plus Fences, which can't be previewed in jsr166y since
>> it relies on JVM support. See
>> Plus possibly some sort of customized hash map.
>> The main reason for delay on that is algorithmic:
>> Efficient support for features like eviction and
>> memoization across a large enough range of
>> policies to be worth supporting in concurrent maps is not a
>> fully solved problem. I want to make sure that
>> we offer only that range of them for which we are
>> very sure we can support well, but without closing
>> the door to future algorithmic overhauls.
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest