TrackingCollectionChangedEventArgs Generics

[stefnotch]

Is there a reason why TrackingCollectionChangedEventArgs isn't a generic class? TrackingHashSet<T> and other classes are generic, so, it seems like it would make sense to make the events generic as well.
As in:

public class TrackingCollectionChangedEventArgs<T> : EventArgs
{
	public TrackingCollectionChangedEventArgs(NotifyCollectionChangedAction action, T item, T oldItem, int index, bool collectionChanged);
	public TrackingCollectionChangedEventArgs(NotifyCollectionChangedAction action, object key, T item, T oldItem, bool collectionChanged);
	public NotifyCollectionChangedAction Action { get; }
	public T Item { get; }
	public T OldItem { get; }
	public object Key { get; }
	public int Index { get; }
	public bool CollectionChanged { get; }
}

[Kryptos-FR]

How would you register a handler for any kind of collection change? If it was generic you could only register to a specific type. So you would need to know in advance which types will be used in collections and have one handler per type, hardly a workable solution.

[stefnotch]

Here are a bunch of cases where TrackingCollectionChangedEventArgs gets used:

xenko/sources/common/core/SiliconStudio.Core/Collections/TrackingCollection.cs

Line 21 in 6fca455

public event EventHandler<TrackingCollectionChangedEventArgs> CollectionChanged

^Not an issue, because TrackingCollection is a generic class.
.

xenko/samples/Templates/TopDownRPG/TopDownRPG/TopDownRPG.Game/Gameplay/EnableDynamicNavigation.cs

Line 30 in 6fca455

private void GameSystemsOnCollectionChanged(object sender, TrackingCollectionChangedEventArgs trackingCollectionChangedEventArgs)

^Not an issue either, because the programmer clearly knows which types he is expecting.
.

xenko/sources/common/core/SiliconStudio.Core/Collections/TrackingHashSet.cs

Line 25 in 6fca455

public event EventHandler<TrackingCollectionChangedEventArgs> CollectionChanged

^Not an issue, since TrackingHashSet is a generic class.
.

xenko/sources/common/core/SiliconStudio.Core/Collections/TrackingDictionary.cs

Line 27 in 6fca455

private EventHandler<TrackingCollectionChangedEventArgs> itemAdded;

^TrackingDictionary is generic. And this is probably not an issue either.
.

xenko/sources/engine/SiliconStudio.Xenko.Input/VirtualButton/VirtualButtonConfig.cs

Line 23 in 6fca455

CollectionChanged += bindings_CollectionChanged;

^VirtualButtonConfig : TrackingCollection<VirtualButtonBinding> The type is known
.

xenko/sources/engine/SiliconStudio.Xenko.Engine/Engine/Scene.cs

Line 115 in 6fca455

private void Children_CollectionChanged(object sender, TrackingCollectionChangedEventArgs e)

^The type is also known here
.

xenko/sources/engine/SiliconStudio.Xenko.UI/Panels/Panel.cs

Line 117 in 6fca455

protected void LogicalChildrenChanged(object sender, TrackingCollectionChangedEventArgs trackingCollectionChangedEventArgs)

^The type is known
.

xenko/sources/common/core/SiliconStudio.Core/Collections/ITrackingCollectionChanged.cs

Line 7 in 6fca455

public interface ITrackingCollectionChanged

^The interface ITrackingCollectionChanged can easily be turned into a generic one
.
.

xenko/sources/scripts/ScriptShader/Effects/Deprecated/ParticleProcessor.cs

Line 69 in 6fca455

data.Emitter.OnMeshUpdate(data.Entity, new TrackingCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset, null, null));

^This might be an issue. However, if I'm not mistaken, all of those cases can be worked around by having some code that ensures backwards compatibility:

class TrackingCollectionChangedEventArgs<T> 
{
	public static implicit operator TrackingCollectionChangedEventArgs(TrackingCollectionChangedEventArgs<T> stuff)
	{
		return (X<object>)stuff;
	}
}

class TrackingCollectionChangedEventArgs : TrackingCollectionChangedEventArgs<object>
{
			
}

Let me know if you find a case that wouldn't work. Or if I made a mistake somewhere.