Just a small trick is that you could use the following using ISet = ISet<object>;
This way all ISet definititions in your code will be of type ISet<object> but be read as ISet. That would make for example SessionImpl changes reduced to one additional using statement at the top. On Thu, May 17, 2012 at 10:19 PM, Patrick Earl <[email protected]> wrote: > 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 >> > > -- Ramon
