...premature send there while I was constructing examples.
// produces the same collection instance type it is handed
C sort<T,C>(C input) where C : ICollection<T>, new() {
var output = new C ();
// do something to produce a sorted version of input
return output;
}
// Allows the caller to control the instance type, but now they always have
to specify it
D sort<D,T,C>(C input) where D : ICollection<T>, new() where C :
ICollection<T> {
var output = new D ();
// do something to produce a sorted version of input
return output;
}
In closing, I'm trying to illustrate that each successive step towards
flexibility in the declaration of this function both made it larger, more
confusing to read, and more work to call.
Go is trying to address implementation dependence through structural
typing. I think I prefer a Sather-like route of making implementation
inheritence a decision made by the subtype implementor, not the type
creator. (aka, all classes are effectively interfaces, and we choose to
either "inherit" them or "conform" to them)
Regarding implementation selection... I think we could get much more
flexible behavior "by default" by having all allocators implicitly define
type-paramaters which are "defaulted" to the selected type, but which can
be overridden by a caller.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
