[concurrency-interest] overview new features -> tim.

Peter Veentjer - Anchor Men p.veentjer at anchormen.nl
Tue Sep 6 02:04:07 EDT 2005

I like to have a small interface so making implementations is easy
and are easy to reason about. If I need buffering (queuing) I could
chain (decorate) channels, the same goes for other functionality like regulating 
(closing/opening channels) or monitoring. There is no reason this
functionality should be declared in the root interface. 
example of chaining:
OutputChannel c = someChannel;//every channel implement in/outputchannel
c = new MonitoringOutputChannel(c);
c = new LoggingOutputChannel(c);
Channel newChannel = new ComposedChannel(c,someChannel);
In this example a new channel (with logging and monitoring) is created 
based on someChannel. This works great and a wide root interface
isn`t required.


From: Doug Lea [mailto:dl at cs.oswego.edu]
Sent: Tue 9/6/2005 1:48
To: Peter Veentjer - Anchor Men
Cc: concurrency-interest at altair.cs.oswego.edu
Subject: Re: [concurrency-interest] overview new features -> tim.

Peter Veentjer - Anchor Men wrote:
> I don`t think that is a very good solution because the exchange of messages is combined
> with storage of messages.

That was my original rational for dl.uti.concurrent versions. But the
rest of the world (including, now, me) disagrees. Support for standard
Collection methods was probably the most frequently requested feature.
Integration into Collections makes these classes more widely usable. And
(sorry to say) the only people inconvenienced by it can cope
with this a lot more easily than if it were the other way around.


More information about the Concurrency-interest mailing list