Well, that's flattering I guess :)

But it's not as bad as it sounds and the only way (AFAIK) to be able to work with both polymorphic objects and have the convenience (and type checking) of a generic counterpart. Limiting yourself to just a generic object/interface unfortunately breaks a lot of design patterns. It's also safe afaik since the only thing the generic version does is some casting and it's generic parameter enforces that casting.

but if you have a better way I'm genuinely interested to hear it

I agree with @ahoka that the advice is bad.

> Limiting yourself to just a generic object/interface unfortunately breaks a lot of design patterns.

Which ones and why?

> It's also safe afaik since the only thing the generic version does is some casting and it's generic parameter enforces that casting.

If you don't have a known constraint that is enforced by the type system then it can never be 'safe'.

You can't pass generic interfaces to other classes that should handle non-generic interfaces (that aren't dependent on the generic constraint)

>If you don't have a known constraint that is enforced by the type system then it can never be 'safe'.

I don't quite know what you mean by this. If you cast to your "T" then casting is ensured. I guess there's some margin for error in that you must enter your casting code to be correct, but it's pretty hard to mess that part up, granted not as good as enforced genericy. Note that in many instances you only initialize generic classes, but you needed to be extract a non-generic interface from then to pass to other classes.

> You can't pass generic interfaces to other classes that should handle non-generic interfaces (that aren't dependent on the generic constraint)

I'd like to see an example of what you mean. You can absolutely pass generic values to other classes. If the type you're passing the generic value to is not generic then the method should be. If you are casting then 99 times out of 100 you have a problem with your code because the types aren't compatible. i.e.

    static void DoSomethingGeneric<A>(A value) => ...

    static void DoSomethingSpecific(string value) => ...


    IEnumerable<int> array = new [] { 1, 2, 3, 4, 5 };

    DoSomethingGeneric(array.First());   // Works
    DoSomethingSpecific(array.First());  // Can only ever work if array is a string[]

> If you cast to your "T" then casting is ensured.

If you 'get out' of the generic situation by casting to an object or dynamic, then at some point you're going to have to cast back to a concrete type. That is the point where your code will blow up. You're carrying ticking time bombs as values.

Hi, sorry for the delay, had to pop into a meeting. I tried to make a very scaled down example of what I mean. It's hard to imagine a real-world scenario from this but assume that according to the architecture we need to separate concerns this way.

The point is that in some cases you want to be able to pass a more general interface while getting some Type-checking and convenience of generics.

In this case we want to hold on to PopProtocolSender and perhaps use it as a variable somewhere. When we use it we need to acccess it's specific IPopProtocol Protocol Property. But we also want to be able to treat it as a general IProtocolSender that has a IProtocol Property, so it can be sent to other classes that takes that interface.

These kinds of situations mainly arise when you have a more complicated architecture. If there's a better way to have your cake and eat it too I'd be glad to know it :)

    public interface IPopProtocol : IProtocol
    {
        void SomeUniqueMetod();
    }

    public interface IProtocol
    {
    }

    public interface IProtocolManager
    {
        void SendMessage(IProtocol protocol, string message);
    }

    public interface IProtocolSender
    {
        IProtocol Protocol
        {
            get;
        }
    }

    public class PopProtocol : IPopProtocol
    {
        public void SomeUniqueMetod()
        {
        }
    }

    public class Program
    {
        public void DoStuff()
        {
            var sender = new PopProtocolSender ();
            var manager = new ProtocolManager();
            manager.SendMessage(sender.Protocol, "Testing");
            sender.Protocol.SomeUniqueMethod();
        }
    }

    public class ProtocolManager : IProtocolManager
    {
        public void SendMessage(IProtocol protocol, string message)
        {
        }
    }

    public class ProtocolSender : IProtocolSender
    {
        protected readonly IProtocol _protocol;

        public ProtocolSender(IProtocol protocol)
        {
            _protocol = protocol;
        }

        public IProtocol Protool => _protocol;
    }

    public class PopProtocolSender : ProtocolSender<IPopProtocol>
    {
        public PopProtocolSender() : base(new PopProtocol)
        {
        }
    }

    public class ProtocolSender<T> : ProtocolSender where T : IProtocol
    {
        public ProtocolSender(T protocol) : base(protocol)
        {
        }

        public new T Protocol => (T)_protocol;
    }

I understand what you're getting at, but why not simply make both IProtocolSender and ProtocolSender generic. Here's a functioning example I based on yours that just compiled and ran in LinqPad without any issues:

    public interface IPopProtocol : IProtocol
    {
    	void SomeUniqueMethod();
    }
    
    public interface IProtocol
    {
    }
    
    public interface IProtocolManager
    {
    	void SendMessage(IProtocol protocol, string message);
    }
    
    public interface IProtocolSender<out T> where T : IProtocol
    {
    	T Protocol
    	{
    		get;
    	}
    }
    
    public class PopProtocol : IPopProtocol
    {
    	public void SomeUniqueMethod()
    	{
    		Console.WriteLine($"Hi, I'm {nameof(PopProtocol)}");
    	}
    }
    
    void Main()
    {
    	var sender = new ProtocolSender<IPopProtocol>(new PopProtocol());
    	var manager = new ProtocolManager();
    	manager.SendMessage(sender.Protocol, "Testing");
    	sender.Protocol.SomeUniqueMethod();
    }
    
    public class ProtocolManager : IProtocolManager
    {
    	public void SendMessage(IProtocol protocol, string message)
    	{
    	}
    }
    
    public class ProtocolSender<T> : IProtocolSender<T> where T : IProtocol
    {
    	private T _protocol;
    	public  T Protocol => _protocol;
    	
    	public ProtocolSender(T protocol)
    	{
    		_protocol = protocol;
    	}
    }

Not sure what the fuss is: you can use SendMessage as usual, and also have access to SomeUniqueMethod.

EDIT:

Also please note that the signature for the generic IProtocolSender uses the out keyword, making it covariant. This will allow you to cast IProtocolSender<IPopProtocol> to IProtocolSender<IProtocol> if you need to, or to pass an IProtocolSender<IPopProtocol> object to a method that expects an IProtocolSender<IProtocol>.

I've been writing c# for around 12 years (on multi million line code bases) and have never had the problems you state, and the example you gave has been shown to not be an issue.

The idea that the propagation of type safety is an issue is something I find bewildering, sorry.

Well, I've been writing C# for 17 years, and I've came across it twice, so it is a very niche solution for certain circumstances. I can't say it's the only solution, but in those instances it was the one that offered the best type safety and allowed classes to have non-generic interfaces.

Say that we have some kind of datastorage where everything is an IEntity, and we need to be able to treat them as such. Them we have a specific entity IApple : IEntity. Every IEntity has IVersion as a Version property, that is passed in it's implementation's construction. IApple has a more specific IAppleVersion as it's Version Property. When we're working with an IApple instance we want to be able to have access to the version as IAppleVersion. But other classes handles only IEntities with IVersions. In this case it makes sense to have the Version as a generic parameter to the class:

Apple : Entity<IAppleVersion>

which makes sure its constructor is:

Apple(IAppleVersion version).

We need to put the stuff that's shared between all entities in the non-generic Entity class, add the Typing of version in a generic version of Entity so Apple can expose the type provided. The Apple class that implements IApple has specific methods for its type. Both entity classes are abstract so they will never be initiated.

I'm not sure that's clear but I hope you can see the problem that I'm trying to solve. I think it's the disconnect with wanting to be able to access both more specific and more general interfaces (and their properties) that causes trouble.

On the flip side, if we have a legitimate need for both a more specific and a more general version of an class/interface, can you tell me a specific reason the way I showed would be bad. It's easy to get hung up "new" is bad because it's 95% true, but as with everything there are exceptions.

But if you never have the need for it, don't use it. I stand by my opinion though that you should be careful and in some situations be able to provide non-generic interfaces rather than requiring each method and class in a library to be generic, but that's only my opinion man :)

> In this case it makes sense to have the Version as a generic parameter to the class

No it really doesn't. It makes sense to use inheritance properly:

    public interface IVersion
    {
        string GetVersion();
    }

    public class Version : IVersion
    {
        string version;

        public Version(string version)
        {
            this.version = version;
        }

        public string GetVersion() =>
            version;
    }

    public class AppleVersion : IVersion
    {
        string version;

        public AppleVersion(string version)
        {
            this.version = version;
        }

        public string GetVersion() =>
            "apple-" + version;
    }

    public abstract class Entity
    {
        public IVersion Version { get; private set; }

        public Entity(IVersion version) =>
            Version = version;
    }

    public abstract class Apple : Entity
    {
        public readonly AppleVersion AppleVersion;

        public Apple(AppleVersion version) : base(version)
        {
            AppleVersion = version;
        }
    }

That allows for "When we're working with an IApple instance we want to be able to have access to the version as IAppleVersion", as well as general access to the IVersion from an Entity.

If you don't like the storage overhead, you could just downcast knowing that the Version is an AppleVersion:

    public abstract class Apple : Entity
    {
        public AppleVersion AppleVersion => Version as AppleVersion;

        public Apple(AppleVersion version) : base(version)
        {
        }
    }

> I'm not sure that's clear but I hope you can see the problem that I'm trying to solve. I think it's the disconnect with wanting to be able to access both more specific and more general interfaces (and their properties) that causes trouble.

You're describing issues with inheritance, not generics.

> I stand by my opinion though that you should be careful and in some situations be able to provide non-generic interfaces rather than requiring each method and class in a library to be generic, but that's only my opinion man :)

That's fine, you're entitled to your opinion, and if it works for you that's great. But your original comment was very 'matter of fact'. I've not seen anything that has communicated to me an issue with generics; and every example so far should have been implemented differently to the way you state (in my opinion).

There's a few downsides with your approach IMO.

a) You now have an AppleVersion Property as well as Version Property, that feels potentially confusing for any user of that class. I now have to find the differently named Version property every time I use an entity?

b) You have to manually write that exact boilerplate code on each specific case of Entity, and there might be a lot more if it isn't a simple example. In my case you get it for free through the generics.

The automatic casting doesn't strike me as a problem, eliminates boilerplate code and the where statement ensures type safety. I've yet to see a single concrete argument against my approach.

I didn't mean it as my way or the highway, I merely wanted to issue a warning on creeping dependencies that generics might cause if you don't have non-generic interfaces, the rest I guess is a matter of taste.

> a) You now have an AppleVersion Property as well as Version Property, that feels potentially confusing for any user of that class. I now have to find the differently named Version property every time I use an entity?

It's a specialised type, so it has specialised behaviour. That's the point of inheritance. You can't put the specialised behaviour in the base because then it's not a specialised type and doesn't understand the context. This is an argument against inheritance.

> b) You have to manually write that exact boilerplate code on each specific case of Entity, and there might be a lot more if it isn't a simple example. In my case you get it for free through the generics.

Yes, every type that has specialised behaviour needs to implement it. And no, you don't get it for free in your version, because you can't have a collection of entities.

    IEnumerable<Entity<Version>>

Or,

    IEnumerable<Entity<AppleVersion>>

All of your complaints about generics appear to be because you're using them to add specialisation to non-specialised types. That will always cause headaches, and that's why, I assume, you have the opinion you do on generics.

> because then a generic requirement will propagate through the whole framework.

And? Why is this a bad thing? Are you trying to maintain compatibility with .NET 1.0 for some reason?

> And some polymorphism/patterns simply won't be possible. Trust me, I've encountered this problem several times

Which patterns? Please demonstrate the problem.

> have a generic version that overrides the properties (with new)

is the horrible bit. You should almost NEVER override with "new".

I agree, this is one of the few exceptions, in fact the only, exception I encountered. But this is a solution for a very specific problem in certain solutions, not a something you tend to do all the time

It is not only good advice, it is required in fair amount of situations because of limitations in the C# language.

It's terrible advice. What limitations are you thinking of?

    interface IValidator<T> {
        bool Validate(T thingToValidate);
    }
    class ThingValidator : IValidator<Thing> {}
    class ThingValidator : IValidator<OtherThing> {}

    var validators = GetAllValidators();

What type is `validators`?

What sensible thing could you do with a list containing a ThingValidator and OtherThingValidator? Assuming there's no relationship between Thing and OtherThing you're forced to use runtime checking to find the validator you need for something typed as object, so at that point you have to use casting or reflection, which you'd also need to do when implementing a non-generic interface.

> You are thinking that using reflection and casting at runtime is not a sensible thing because it is not optimal

No I'm not thinking that, I'm saying that implementing a non-generic base interface like

    public interface IValidator {
        bool Validate(object obj);
    }

is pointless because you'll have to do the same type checking/casting in Validate you would have to do in a wrapper which implemented IValidator<object>. Requiring a base interface is worse because you'll have to implement the same boilerplate implementation of Validate(object) in every implementing class - see IEnumerable/IEnumerable<T> as an example.

> Obviously this library will need to do run-time casting of types

You've linked to a clojure library which is dynamically typed so I don't see how this is relevant. It's not obvious to me why a C# version would require casting.

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.

> To run all of these validators against a given class you have three (un)reasonable choices:

You only need to write one wrapper class which encapsulates the cast you'd have to do anyway in a non-generic IValidator interface:

    public class Wrapper<T, TBase> : IValidator<TBase>
    {
        private readonly IValidator<T> inner;
        public Wrapper(IValidator<T> v)
        {
            this.inner = v;
        }
        public bool Validate(TBase b)
        {
            if(b is T)
            {
                return this.inner.Validate((T)(object)b);
            }
            else return false;
        }
    }

> 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.

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.)

The signature of GetAllValidators must be: GetAllValidators<T>();

So it's whatever type of T you pass to GetAllValidators.

Not to mention that in the original example IValidator is invariant...it can be far more flexible by making it covariant (IValidator<out T>) so that GetAllValidators can also be used on more derived types.

And then you can do for example:

    var validators = GetAllValidators<EntityBase>();

Where validators might be IEnumerable<IValidator<EntityBase>>. Compile-time type safety is preserved and each individual validator's generic type can be any type that is derived from EntityBase.

:)

The question here is, what good is a collection of all validators? If you want to perform validation, you're starting with an item (to validate) and you know its type, so it shouldn't be a problem to get the correct IValidator<T> for it. If you really need to have a common base for all validators, explicit interface implementation is a better choice than hiding methods with new:

    interface IValidator
    {
      bool Validate(object item);
    }
    
    interface IValidator<T> : IValidator
    {
      bool Validate(T item);
    }
    
    abstract class Validator<T> 
      : IValidator<T> where T : class
    {
      public abstract bool Validate(T item);
      
      bool IValidator.Validate(object item)
      {
        var typedItem = item as T;
        if (typedItem == null)
          throw new InvalidOperationException();
        
        return Validate(typedItem);
      }
    }

This code wouldn't compile, for starters.

But it could be `IValidator<object>`, in the worst case. That being said, why not make a `class ThingValidator<T> : IValidator<T> {}`, for all the lack of detail we have?

There aren't enough details here to demonstrate the weaknesses of generics.

The reason it won't compile is that the code, as given, has two classes with the same name.