>>Collection!(Object) foo;
>>Collection!(String) bar;
>>
>>foo.addAll!(MyCollection!(String))(bar);
>>versus
>>foo.addAll(bar);
>>
>>Personally find the first one moderately unwritable and perfectly
>>unreadable ;)
>>
> My first try to investigate this was to use:
>   class Collection(T:Object) {
>     void addAll(Collection!(Object) x) {}
>   }
> and then hope that Collection!(String) could be implicitly cast to
> Collection!(Object) but it failed to compile the addAll declaration.
You certainly shouldn't be able to do this. Java lets you cast T[] to S[] where T is a subclass of S, and the result is the possibility that
t[0]=a; gives you a runtime exception, if t a T[] variable that points to an S[], and a is a T but not an S. As much as I'd like it to be most of the time, Foo!(S : T) is-not-a Foo!(T).
In this case, this would break type checking by allowing you to add any Object. Of course it won't work for ints either.

> So my first guess is that templates might not be the right way to do what
> you want to do. That doesn't mean there isn't a problem with templates
> but I'm not sure this is a great example.
I'm basing this on Java, which (IMO and ignoring the runtime problems) seems to be pretty well done using templates.

For the record, my ideal definition would be
interface Collection(T) {
	template addAll(S:T) {
		void addAll(Collection!(S) c);
	}
}
class LinkedList(T) : Collection!(T) {
	template addAll(S:T) {
		void addAll(Collection!(S) c) {
			foreach(S s;c)
				add(s);
		}
	}
}
(Actually there'd be a List interface in between).
I'm not sure if
template addAll(S:T) or
template addAll(S:T,Collection!(S)) or
template addAll(Collection!(S:T))
are the most likely to ever be supported by deduction, but the syntax
foo.addAll!(bar.T)(bar) isn't much better than
foo.addAll!(typeof(bar))(bar)
in terms of readability.

On an unrelated note having a template around every templated function is awkward, can we have some sugar please? ;) It'd also make me less nervous about exactly how overriding works when it's inside a template.

> This looks to me like a bug in class template syntax.
> So my second attempt was
>   interface Collection {
>     void addAll(Collection x);
>   }
>   class LinkedList(T): Collection {
>     void addAll(Collection x){}
>   }
> and this worked fine when called with
>   Collection foo = new LinkedList!(String);
>   Collection bar = new LinkedList!(String);
>   foo.addAll(bar);
As you pointed out, this isn't useful, as you'd find when you come to implement it.

void addAll(Collection x) {
	foreach(T item;x){	// WTF is T?
		add(item);
	}
}

Even if you decide collections only hold objects, it isn't typesafe.
Sam

Ben Hinkle wrote:

> Take Two. Collections are just waay to much fun to putter around with :-)
> Here's an example that results in calls that look like
>   TmixCollectionTypes!(Object,String).addAll(foo,bar);
Nice, but this should be a member function. More specifically, there might be a better way for some collections than add() one item at a time.

I guess my problem with these solutions is I want templates to help me - I want to give my variables more descriptive types and in exchange I want better type checking. I don't want to care about templates until there's a problem.

Sam

"Sam McCall" <tunah.d@tunah.net> wrote in message news:c1dm0t$2ob1$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
> > Take Two. Collections are just waay to much fun to putter around with
:-)
> > Here's an example that results in calls that look like
> >   TmixCollectionTypes!(Object,String).addAll(foo,bar);
> Nice, but this should be a member function. More specifically, there might be a better way for some collections than add() one item at a time.

Note it would have to be a static member function - see the section "Limitations" in the Templates doc. Virtual template member functions are mind-bending (at least to me) since there would have to be vtable slots for every possible template instantiation.

>
> I guess my problem with these solutions is I want templates to help me - I want to give my variables more descriptive types and in exchange I want better type checking. I don't want to care about templates until there's a problem.
>
> Sam

Ben Hinkle wrote:

>>>Here's an example that results in calls that look like
>>>  TmixCollectionTypes!(Object,String).addAll(foo,bar);
>>
>>Nice, but this should be a member function. More specifically, there
>>might be a better way for some collections than add() one item at a time.
> 
> 
> Note it would have to be a static member function - see the section
> "Limitations" in the Templates doc.
Oh yeah :-\
> Virtual template member functions
> are mind-bending (at least to me) since there would have to be vtable
> slots for every possible template instantiation.
Yeah, I was thinking of just being able to override
template foo!(A,B:C) { void foo(A a,B b); }
with
template foo!(D,E:C) { void foo(D d,E e); }
but I'm sure it quickly gets too complicated.
Sam

Sam McCall wrote:
>
> Nice, but this should be a member function. More specifically, there might be a better way for some collections than add() one item at a time.

In some cases this couldn't be a member function.  Arrays, for example.

> I guess my problem with these solutions is I want templates to help me - I want to give my variables more descriptive types and in exchange I want better type checking. I don't want to care about templates until there's a problem.

I'm considering using free-functions to return iterators much like begin, end, etc, as they exist in the C++ standard library.  Not having to explicitly specify template arguments for these functions would be a nice perk, but I think it will work out either way.


Sean