dcollections 1.0 and 2.0a beta released

Michel Fortin michel.fortin at michelf.com
Sat May 22 04:56:31 PDT 2010


On 2010-05-21 22:55:16 -0400, Walter Bright <newshound1 at digitalmars.com> said:

> Walter Bright wrote:
>> If we can get anywhere close to that level of success with ranges and 
>> containers, we should all be well pleased.
> 
> Mike Taylor has a phrase for that I think is well-coined: "impedance matching",
> defined as the work necessary to get one library module to work with another
> library module.

This makes me think about something.

In principle, I like the idea of containers being reference type. It 
works well when passing a container to functions. But at the same time, 
I despite it. By-reference containers forces you to have extra 
indirections even when you don't need them, and you have to worry about 
null. Sometime a value-type would be better, when creating more complex 
data structures for instance:

	class Channel {
		private {
			Array!Message inbound;
			Array!Message outbound;
		}

		...
	}

What's the point of having extra indirection here?

I've been thinking about having both by-value and by-reference 
containers. The first-class name would be given to the by-reference 
container to give it more visibility, but that by-reference container 
would be a simple wrapper for a by-value container "part" implemented 
in a struct:

	struct ArrayPart(T) { ... } // by value array container.

	class Array(T) {
		ArrayPart!T part;
		alias part this;
	}

So now, if you want to reuse a container "part" to build some kind of 
more complex data structure, you can do it like this:

	class Channel {
		private {
			ArrayPart!Message inbound;
			ArrayPart!Message outbound;
		}

		...
	}

No silly extra indirection.

That said, all this gives me a feeling of an overcomplicated design. 
After all, the problem is that you want to pass the container by 
reference in function arguments, but it's __too easy to forget the 
ref__. Perhaps that's the problem that should be fixed.

Couldn't we just make a struct that cannot be implicitly copied? 
Perhaps something like this:

	@explicitdup struct Array {  }

	void testVal(Array array);
	void testRef(ref Array array);

	unittest {
		Array array;
		testVal(array);     // error, cannot copy array implicitly
		testVal(array.dup); // ok, array is copied
		testRef(array);     // ok, array is passed by reference
	}

If there's already a way to achieve this, I couldn't find it.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d-announce mailing list