News for hackers. Stuff that matters.
Re:How the .NET Runtime Loads a Type by ludston on Friday June 16, 2017 @02:06PM (#14571282)
> Task/Task<T> does follow the pattern but they could have simply introduced a Unit type in the BCL and replaced the non-generic Task type with Task<Unit> instead.

Microsoft could have added some unified Unit type but they did not, which makes this irrelevant.

Just because there is an obvious negative consequence to choosing a particular type schema (e.g. IEnumerable<t> extending IEnumerable) does not mean that the pattern is pointless. Sometimes biting the bullet is necessary since C# has a bullshit type system that makes dynamic orchestration a pain in the arse.

Re:How the .NET Runtime Loads a Type by lkitching on Friday June 16, 2017 @03:14PM (#14571862)
> Microsoft could have added some unified Unit type but they did not, which makes this irrelevant.

It's not irrelevant - you're using Task/Task<T> as an example of the non-generic base type/generic subtype pattern being necessary, but it isn't.

IEnumerable<T> extending IEnumerable is a consequence of C#1 not supporting generics at all, and the non-generic version would not be necessary if it had. I was just using it as a common example of the boilerplate the pattern incurs.

Re:How the .NET Runtime Loads a Type by ludston on Friday June 16, 2017 @06:07PM (#14572991)
No, I was using IValidator, IValidator<t> as an example of a non generic base type being necessary when interfacing with existing libraries...

Honestly if you can that clojure library I linked a few posts ago without using this technique I will be extremeley impressed, but otherwise I disbelieve you. (Note: I have done this a few years ago.)