1
\$\begingroup\$

I've just gotten into some C# programming and decided to expand my knowledge of how games are made in C# by looking through some open-source frameworks. While doing this I noticed something very odd; classes that they make would implement both generic and non-generic interfaces that represent the same data structure. For example:

public class SomeSpecialList<T> : IList<T>, IList {
    ...
}

I couldn't find any explanation to this - Is this something I should be thinking about when programming games in C#? Why? Is it a performance thing?

Improve this question
\$\endgroup\$
3
  • \$\begingroup\$ Related: stackoverflow.com/questions/14002674/… \$\endgroup\$
    – Bálint
    Jul 20, 2017 at 15:13
  • \$\begingroup\$ Generics weren't in version 1.1 of the .NET Framework, and a lot of APIs that have existed forever don't use them. Implementing both will make your code compatible with legacy code that doesn't use generics, including old framework code. If you don't need it, don't bother, but it doesn't cost anything to add. \$\endgroup\$
    – error
    Jul 20, 2017 at 15:18
  • \$\begingroup\$ @error Backwards compatibility makes sense, I just figured since I saw it used in most of the game frameworks it may be related to something else that games might gain some extra benefit from (sorting, iteration speed, etc). But if that's not the case I should probably close this question since it turns out to have very little to do with game development. \$\endgroup\$
    – Charanor
    Jul 20, 2017 at 15:31

1 Answer 1

Reset to default
2
\$\begingroup\$

By implementing both IList and IList<T> you allow your type to have maximum (or at least, more) generality. Code that expects an IList (generally older code that predates the introduction of generics) can accept instances of your type.

In game development, this isn't as much of a compelling reason as it might be elsewhere. Most of the time backwards compatibility with some of the legacy APIs that accept non-generic collections isn't a huge deal. If you're writing framework-level code, especially framework-level code you intend to distribute to the wider internet (so you don't know precisely who will be consuming it and what their personal needs will be), that provides a stronger rationale for why you'd want to implement both. That may explain why you've come across it in a lot of available frameworks.

If you're just writing game-specific, non-reusable code? It's not a big deal (and you should prefer to implement the generic version as its nicer to use). On the other hand, the extra work needed to implement the non-generic version is usually quite small, so maybe why not?

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ If I'm not mistaken, there are also some generic interfaces that require you implement non-generic versions, right? IEnumerable<T> requires implementing IEnumerable.GetEnumerator() if I recall correctly. \$\endgroup\$
    – DMGregory ♦
    Jul 20, 2017 at 16:35
  • \$\begingroup\$ Yes; it is possible for a generic interface to itself mandate implementation of a non-generic interface, and IEnumerable<T> is one such example (it's basically declared as "IEnumerable<T> : IEnumerable." \$\endgroup\$
    – user1430
    Jul 20, 2017 at 16:37

Not the answer you're looking for? Browse other questions tagged .