Comments on: FGF: A Collection Class with Events http://jsedlak.org/2010/01/31/fgf-a-collection-class-with-events/ Wed, 14 Sep 2011 00:30:46 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: John Sedlak http://jsedlak.org/2010/01/31/fgf-a-collection-class-with-events/comment-page-1/#comment-1287 John Sedlak Mon, 01 Feb 2010 11:13:54 +0000 http://jsedlak.org/?p=573#comment-1287 I am assuming that you are speaking about the event portion of the code when you talk about avoiding generics? The reason for this is that a single event handler couldn't listen to multiple lists. It is a very small and insignificant reason, I know, but it also allows for complete coverage of use cases. As for deriving from System...Collection - I honestly didn't know it existed. I will have to double check to see if this object is available on the 360 and Zune HD because Reflector seems to be having issues reflecting on them. The reason for the index and the object is because originally this interface was modeled after the INotifyCollectionChanged interface, which supplies both the index and the object as well as another parameter telling how the collection was changed. I am hoping that with the release of .NET 4.0, this interface will be better placed in the framework's libraries such that I can use it. This will give me interoperability with other .NET software. Again, the fact that the index exists does not limit the use to index based collections but does supply complete coverage which is an overriding goal for FGF. The point here is that if it is needed or can be used, the index parameter is there. If it weren't there than the use would be limited to non-indexable collections. Having said all that, your implementation seems perfectly reasonable and is a good way of approaching the situation. I am assuming that you are speaking about the event portion of the code when you talk about avoiding generics? The reason for this is that a single event handler couldn’t listen to multiple lists. It is a very small and insignificant reason, I know, but it also allows for complete coverage of use cases.

As for deriving from System…Collection – I honestly didn’t know it existed. I will have to double check to see if this object is available on the 360 and Zune HD because Reflector seems to be having issues reflecting on them.

The reason for the index and the object is because originally this interface was modeled after the INotifyCollectionChanged interface, which supplies both the index and the object as well as another parameter telling how the collection was changed. I am hoping that with the release of .NET 4.0, this interface will be better placed in the framework’s libraries such that I can use it. This will give me interoperability with other .NET software.

Again, the fact that the index exists does not limit the use to index based collections but does supply complete coverage which is an overriding goal for FGF. The point here is that if it is needed or can be used, the index parameter is there. If it weren’t there than the use would be limited to non-indexable collections.

Having said all that, your implementation seems perfectly reasonable and is a good way of approaching the situation.

]]> By: Markus Ewald http://jsedlak.org/2010/01/31/fgf-a-collection-class-with-events/comment-page-1/#comment-1286 Markus Ewald Mon, 01 Feb 2010 07:01:59 +0000 http://jsedlak.org/?p=573#comment-1286 Having taken that route already, allow me to make some suggestions ;-) Is there any reason why you avoid generics in that code? I would hate to have to downcast in the event handler. Especially since with this design, if I later changed the collection's type, those downcasts would still happily compile and only fail a runtime. You also don't seem to derive from System.Collections.ObjectModel.Collection (which is made for this purpose and would implement IList, ICollection, IEnumerable, IList, ICollection and IEnumerable for you) Supplying an index *and* the object seems redundant. Such a talkative interface limits the concept to indexable collections. I have had a use for observable dictionaries in the past :) Here's my hammer for the same nail: :P https://devel.nuclex.org/framework/browser/Nuclex.Support/trunk/Source/Collections/ItemEventArgs.cs https://devel.nuclex.org/framework/browser/Nuclex.Support/trunk/Source/Collections/ObservableCollection.cs https://devel.nuclex.org/framework/browser/Nuclex.Support/trunk/Source/Collections/ObservableDictionary.cs Having taken that route already, allow me to make some suggestions ;-)

Is there any reason why you avoid generics in that code? I would hate to have to downcast in the event handler. Especially since with this design, if I later changed the collection’s type, those downcasts would still happily compile and only fail a runtime.

You also don’t seem to derive from System.Collections.ObjectModel.Collection (which is made for this purpose and would implement IList, ICollection, IEnumerable, IList, ICollection and IEnumerable for you)

Supplying an index *and* the object seems redundant. Such a talkative interface limits the concept to indexable collections. I have had a use for observable dictionaries in the past :)

Here’s my hammer for the same nail: :P
https://devel.nuclex.org/framework/browser/Nuclex.Support/trunk/Source/Collections/ItemEventArgs.cs
https://devel.nuclex.org/framework/browser/Nuclex.Support/trunk/Source/Collections/ObservableCollection.cs
https://devel.nuclex.org/framework/browser/Nuclex.Support/trunk/Source/Collections/ObservableDictionary.cs

]]>