I have started to continue Ben's excellent work in porting Doug Lea's concurrent library to D, and I'm not sure what approach is best in all cases.

D has a different featureset than Java, so there are issues that must be considered when porting Java code to D. Here is the basic philosophy I've been considering for porting the concurrent library:

	* Being faithful to Doug's original Java code is less important than
	  creating a good library.
	* Type safety is good. Lean towards avoiding casts when possible.
	* Minimalism is good. The interface should not be unnecessarily complicated.

To this end, I'm considering the below changes. A couple are going to be a bit
controversial, so I'm curious to see what people think.

	* Collection-type classes use templates. It's annoying to have to cast the
		output all the time, and it's simple enough to alias a TFoo!(Object)
		instantiation, so you can have a Java-style class if you want.

	* Use of delegates instead of a Runnable interface. Since both strategies
		allow state to be carried in an object, there's no reason to require a
		Runnable. Requiring the use of a class would be a disadvantage, in fact,
		because of D's lack of inner class support.

	* Some constructs don't need to support primitive types. I'm referring to
		the Channel interface here. The API and the implementation would be
		simpler if the stored objects could be null. Since this is expected to be
		the common case, I think this would be fine. To store a primitive in such
		a container, a small templated class could be made, something like:

			class ObjectBox(T) {
					T var;
				public:
					this(T t) { var = t; }
					T get() { return var; }
			}

		I think that this solution would be acceptable in most cases.

I don't see any way in which these changes would reduce the functionality of the library, but I'm curious to see what other people think of them. Ben, guys, what do you think? Is this the way to go?

Mike Swieton
__
But it is vital to remember that information - in the sense of raw data - is
not knowledge; that knowledge is not wisdom; and that wisdom is not foresight.
	- Sir Arthur C Clarke

"Mike Swieton" <mike@swieton.net> wrote in message news:pan.2004.05.07.17.07.08.515726@swieton.net...
> I have started to continue Ben's excellent work in porting Doug Lea's concurrent library to D, and I'm not sure what approach is best in all
cases.
>
> D has a different featureset than Java, so there are issues that must be considered when porting Java code to D. Here is the basic philosophy I've
been
> considering for porting the concurrent library:
>
> * Being faithful to Doug's original Java code is less important than
>   creating a good library.

Agreed - also I started to find Java's "one class per file" a little annoying so I combined things like exceptions and small helper classes into the same files.

> * Type safety is good. Lean towards avoiding casts when possible. * Minimalism is good. The interface should not be unnecessarily
complicated.
>
> To this end, I'm considering the below changes. A couple are going to be a
bit
> controversial, so I'm curious to see what people think.
>
> * Collection-type classes use templates. It's annoying to have to cast the output all the time, and it's simple enough to alias a TFoo!(Object) instantiation, so you can have a Java-style class if you want.

Agreed. Templates gooood. Casting baaaad.

> * Use of delegates instead of a Runnable interface. Since both strategies allow state to be carried in an object, there's no reason to require a Runnable. Requiring the use of a class would be a disadvantage, in fact, because of D's lack of inner class support.

Agreed - though functions should be allowed, too. For example, std.thread allows you to create a thread with a delegate or a function as the "runnable". It is kindof annoying to have the near-duplication of code and fields but I think we just following what thread.d does.

> * Some constructs don't need to support primitive types. I'm referring to the Channel interface here. The API and the implementation would be simpler if the stored objects could be null. Since this is expected to be the common case, I think this would be fine. To store a primitive in such a container, a small templated class could be made, something like:
>
> class ObjectBox(T) {
> T var;
> public:
> this(T t) { var = t; }
> T get() { return var; }
> }
>
> I think that this solution would be acceptable in most cases.

Agreed. My impression is that the typical use case for a Channel is to have multiple worker threads grabbing the objects coming out of a channel and processing them and that really only works if the channel is homogeneous. Items in the channel are probably bigger than a single primitive. Also if the user wants to have custom structs in the channel they can alway subclass some channel and add an API to put/take their struct.

Thanks for helping out!

> I don't see any way in which these changes would reduce the functionality
of
> the library, but I'm curious to see what other people think of them. Ben, guys, what do you think? Is this the way to go?
>
> Mike Swieton
> __
> But it is vital to remember that information - in the sense of raw data -
is
> not knowledge; that knowledge is not wisdom; and that wisdom is not
foresight.
> - Sir Arthur C Clarke
>

In article <pan.2004.05.07.17.07.08.515726@swieton.net>, Mike Swieton says...
>
>I have started to continue Ben's excellent work in porting Doug Lea's concurrent library to D, and I'm not sure what approach is best in all cases.

Well, there was no wailing or gnashing of teeth at this, so here's a tarball of what I've done so far. Feel free to test it and find bugs in it 8-} Feedback of any sort welcome.

Human salvation lies in the hands of the creatively maladjusted.
        - Martin Luther King, Jr.

I'll submit it to the subversion codebase, assuming that is ok with you. Would you like to have write access to the repository?

On Sat, 8 May 2004 18:04:24 +0000 (UTC), Mike Swieton
<Mike_member@pathlink.com> wrote:

>In article <pan.2004.05.07.17.07.08.515726@swieton.net>, Mike Swieton says...
>>
>>I have started to continue Ben's excellent work in porting Doug Lea's concurrent library to D, and I'm not sure what approach is best in all cases.
>
>Well, there was no wailing or gnashing of teeth at this, so here's a tarball of what I've done so far. Feel free to test it and find bugs in it 8-} Feedback of any sort welcome.
>
>Human salvation lies in the hands of the creatively maladjusted.
>        - Martin Luther King, Jr.

On Sat, 08 May 2004 18:07:11 -0400, Ben Hinkle wrote:

> I'll submit it to the subversion codebase, assuming that is ok with you. Would you like to have write access to the repository?
> 

Perfectly fine. Consider my contributions to be public domain.

Write access would be excellent, thank you.

Mike Swieton
__
I've developed a new philosophy. I only dread one day at a time.
	- Charlie Brown

Nice! Can you email a copy to Doug Lea?

"Mike Swieton" <Mike_member@pathlink.com> wrote in message news:c7j7f8$1td1$1@digitaldaemon.com...
> In article <pan.2004.05.07.17.07.08.515726@swieton.net>, Mike Swieton
says...
> >
> >I have started to continue Ben's excellent work in porting Doug Lea's concurrent library to D, and I'm not sure what approach is best in all
cases.
>
> Well, there was no wailing or gnashing of teeth at this, so here's a
tarball of
> what I've done so far. Feel free to test it and find bugs in it 8-}
Feedback of
> any sort welcome.
>
> Human salvation lies in the hands of the creatively maladjusted.
>         - Martin Luther King, Jr.
>

What's a .bz2 file? Can you make it into a .zip file?

"Mike Swieton" <Mike_member@pathlink.com> wrote in message news:c7j7f8$1td1$1@digitaldaemon.com...
> In article <pan.2004.05.07.17.07.08.515726@swieton.net>, Mike Swieton
says...
> >
> >I have started to continue Ben's excellent work in porting Doug Lea's concurrent library to D, and I'm not sure what approach is best in all
cases.
>
> Well, there was no wailing or gnashing of teeth at this, so here's a
tarball of
> what I've done so far. Feel free to test it and find bugs in it 8-}
Feedback of
> any sort welcome.
>
> Human salvation lies in the hands of the creatively maladjusted.
>         - Martin Luther King, Jr.
>

On Tue, 25 May 2004 14:39:02 -0700, Walter wrote:

> What's a .bz2 file? Can you make it into a .zip file?
> 

Common *nix archive format. Don't use that archive anyway; it's since been moved onto Dsource.org. If you have a Subversion client, you can check it out with a command like: svn co http://svn.dsource.org/svn/projects/concurrent

If not, there's a zip up, which will likely be out of date extremely soon (I'm working on it now), at: http://www.csis.gvsu.edu/~swietonm/concurrent.zip

And as to your other message, I don't consider this code production quality yet. Announcing it to Doug may be premature. In any case, I haven't done so yet.

Unless Ben has?

Mike Swieton
__
Ah, well, then I suppose I shall have to die beyond my means.
	- Oscar Wilde, last words

Mike Swieton wrote:

> On Tue, 25 May 2004 14:39:02 -0700, Walter wrote:
> 
>> What's a .bz2 file? Can you make it into a .zip file?
>> 
> 
> Common *nix archive format. Don't use that archive anyway; it's since been moved onto Dsource.org. If you have a Subversion client, you can check it out with a command like: svn co http://svn.dsource.org/svn/projects/concurrent
> 
> If not, there's a zip up, which will likely be out of date extremely soon (I'm working on it now), at: http://www.csis.gvsu.edu/~swietonm/concurrent.zip
> 
> And as to your other message, I don't consider this code production quality yet. Announcing it to Doug may be premature. In any case, I haven't done so yet.
> 
> Unless Ben has?

nope.

> Mike Swieton
> __
> Ah, well, then I suppose I shall have to die beyond my means.
> - Oscar Wilde, last words

"Mike Swieton" <mike@swieton.net> wrote in message news:pan.2004.05.25.22.45.55.222228@swieton.net...
> And as to your other message, I don't consider this code production
quality
> yet. Announcing it to Doug may be premature.

Ok.

> In any case, I haven't done so
> yet.

I agree on waiting until it is done. If he'll host a link to it, that will raise the visibility of it (and D) quite a lot. I also see it as a nice demonstration of techniques for translating Java to D, opening the door to other packages being converted.