Why I chose D over Ada and Eiffel

[H. S. Teoh]

On Tue, Aug 20, 2013 at 08:53:02PM +0200, Timon Gehr wrote:
> On 08/20/2013 08:17 PM, Joseph Rushton Wakeling wrote:
> >
> >Since Clojure is more recent than D, and AFAICT its sequences API seems
> >to have arrived in later versions of the language, I wondered if the
> >influence had been in the opposite direction.
> 
> Unlikely. Stream processing has a long tradition in the lisp community.
> D sacrifices some of its elegance, presumably for more predictable
> performance.
> (Though some of it could be compensated for by having a usable
> function in std.range that forgets the concrete range type and makes
> all ranges of the same element type interchangeable.
> inputRangeObject exists but it is not usable, and also not
> efficient.)

Hmm.  Maybe something like this?

	interface GenericInputRange(E)
	{
		@property bool empty();
		@property E front();
		void popFront();
	}

	GenericInputRange!E genericInputRange(E,R)(R range)
		if (is(ElementType!R == E))
	{
		class GenericInputRangeImpl : GenericInputRange!E {
			R impl;
			this(R range) { impl = range; }
			override @property bool empty() { return impl.empty; }
			override @property E front() { return impl.front; }
			override void popFront() { impl.popFront(); }
		}
		return new GenericInputRangeImpl(range);
	}

	// insert adaptations for forward ranges, et al, here.

I think this might actually be more useful than the current
std.range.inputRangeObject, since this lets you interchange ranges of
different underlying types as long as their element types are the same.

Using an interface rather than a base class also lets user code adapt
their own classes to work with the generic range interface.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry