One modification to my original proposal. In fact, the
OnCollectionChanged method should be virtual instead of abstract, with
an empty default implementation. This is taking into consideration
that it will only be of importance when change notification is
desired. People not interested in change notification won't want to
bother with it.
Yes, please take a look at my blog post. You will see that my
PersistentObservableList<T> and PersistentObservableBag<T> classes
both contain an OnCollectionChanged method as described above
(PersistentObservableSet<T> has one that's slightly different, but it
could be refactored). The solution I created has been working fine
for NH 1.2 through 2.0. The problem is in NH 2.1, as described in my
original post, since collection methods are being explicitly
implemented. Figuring out which (non-virtual) methods to override has
already been a process of hacking. Adding my OnCollectionChanged()
method to AbstractPersistentCollection would be great since this kind
of override hacking with every new NH version would no longer be
necessary.
Well, if you want to consider different implementations, the only
significant variation I can think of is a separate OnCollectionXXX()
method for each modification type. The upside of that would be to rid
you of the NotifyCollectionChangedAction enum, which you might
consider WPF-specific. The downside is that overriding all those
methods is much more verbose than overriding just one, but acceptable
nonetheless since they would be in a dedicated subclass anyway.
Another option would be to find/make another GUI-neatral enum with
more-or-less the same values as what's in
NotifyCollectionChangedAction.
BTW, yes, I did log into JIRA just today for uploading a unit test,
although for an issue not related to the current thread. Do you want
me to create an JIRA issue regarding this request as well?
> On Wed, Nov 26, 2008 at 10:22 AM, Stephen Bohlen <
sboh...@gmail.com> wrote:
> > HappyNomad:
>
> > I will take a look @ the blog post you mention in your initial post and see
> > what we can consider doing that will support the GOAL you have of ensuring
> > that there is a way to observe changes to collections. The implementation
> > may (in the end) be something different than specifically what you are
> > proposing, but the intent of what you are after seems reasonable (to me).
>
> > And for the record, I have to credit Gustavo for chiming-in
> > on UI-neutrality being a cornerstone of any implementation to address this
> > need. [?]
> 32A.png
> < 1KViewDownload