I'm in support of removing it. In the vast majority of scenarios I can
imagine, ISet<T> is going to be used anyways. In those very rare cases
where you just can't decide what you have, ISet<object> seems fine.
Patrick Earl
On Thu, May 17, 2012 at 12:41 PM, Oskar Berggren
<[email protected]>wrote:
> One of the problems with dumping Iesi.Collections is that the BCL
> (even 4.0) have no non-generic ISet.
>
>
> To facilitate the eventual switch to .Net 4 I have pushed a number of
> commits to master which reduce use of the non-generic set collections.
> This still targets .Net 3.5 and I think it's unintrusive enough to be
> acceptable even in a 3.4 (if we do such a release). Most commits
> shouldn't be controversial (replacing private occurrences of ISet with
> ISet<>), but there are some public interfaces that change, detailed
> below.
>
>
> These two seemed fairly straightforward so they are already pushed to
> master, but please speak up if you think this was a bad idea:
>
> QueryKey.cs and related: Use strongly typed ISet<FilterKey> to prepare
> for a world without ISet.
>
> https://github.com/nhibernate/nhibernate-core/commit/78f76cec860a4352a73526c7737d67934faa3c33
>
> Use strongly typed ISet<EntityKey> for
> IPersistenceContext.NullifiableEntityKeys. This match all current use
> inside the NH code base.
>
> https://github.com/nhibernate/nhibernate-core/commit/f2cb250898ddf2bd1abd8290b6c158f0cc4b7e91
>
>
>
> ISet is also used in the IDeleteEventListener interface and related
> code, to track the set of entities which have already been visited. I
> propose to change the interface to use ISet<object> instead.
> I have a patch prepared for this, which is not merged yet:
>
> IDeleteEventListener, IEventSource: Use generic ISet<> instead of
> non-generic in method signatures.
> IdentitySet: Make it inherit Set<object> instead of Set, since the
> latter has no counterpart in SCG.
>
> https://github.com/oskarb/nhibernate-core/commit/f06d4f1c0bc12a94bd60cfd5e66fc013e1b7ef28#diff-8
>
> Any comment on this breaking change?
>
>
> After the above three patches, NHibernate itself no longer relies on
> non-generic sets. The only remaining use in NHibernate core are in the
> 5 classes that support their use in mapped classes. It seems to me
> that as a last resort one can always use an ISet<object> instead of
> ISet. Given that, is there any valid reason to keep support for ISet
> in mapped classes? Apart from backwars compatibility of course.
> Removing that support would surely not be acceptable in 3.4, but only
> in 4.0.
>
>
> /Oskar
>
