I meant: Also, considering the Cost-Benefit-Ratio for implementing *option 2 over option 1 *(yes, the implementation cost: time, resources, etc.), I don't think it would be worth it. I know it's not mine, but just consider it as my concern on it.
On Sun, Oct 7, 2012 at 5:11 PM, Maximilian Raditya <[email protected]> wrote: > Couldn't agree more with pvginkel. > > I have no vote here, but I prefer option 1. To minimize external > depenencies (if not eliminate them all... :D) is an excellent goal to have. > Putting it in "System.Collections.Generic" namespace would be even > better... :D > > > > Option 1 > ... But some users prefer to avoid referencing NHibernate types directly > from e.g. domain logic.... > > I still don't get it. Would it be any better if it's being put in > Iesi.Collections namespace, and then users complain "avoid > referencing Iesi.Collections types directly from e.g. domain logic"? It > doesn't make any senses at all to me. > > > Also, considering the Cost-Benefit-Ratio for implementing it (yes, the > implementation cost: time, resources, etc.), I don't think it would be > worth it. I know it's not mine, but just consider it as my concern on it. > I'd rather make a suggestion to MS in Connect so that they would implement > OrderedSet, say in .NET 5. And by the time it'd arrive, it'd be easier to > switch to .NET built-in OrderedSet. > > > > > On Sun, Oct 7, 2012 at 2:53 PM, pvginkel <[email protected]> wrote: > >> My 'vote' is for option 1. Reworking Iesi would likely result in a >> library that has very little classes left, especially when everything that >> NHibernate doesn't use is removed. To keep this library as a requirement >> would, I think, not justify the added dependency. >> >> I have two alternatives to the approach described in option 1. Firstly, >> it is possible to keep the Iesi namespace, but put the classes in the >> NHibernate assembly. Kind of hybrid approach. Second, instead of putting >> it in the NHibernate namespace, it is also possible to put it in a >> global::System.Collections.Generic namespace in the NHibernate assembly. >> This would also ease migration when Microsoft decided to implement the >> OrderedSet class in a later release. >> >> On Saturday, October 6, 2012 5:09:38 PM UTC+2, Oskar Berggren wrote: >>> >>> Hi, >>> >>> To support the order-by attribute in collection mapping, NHibernate uses >>> the OrderedSet class from Iesi.Collections. Unfortunately there is no >>> corresponding ordered set class available in the BCL in .Net 4. >>> >>> I have implemented a new OrderedSet based on ISet<T>, etc. from .Net 4, >>> but now I'm not sure where to put it. >>> >>> Option 1 >>> Put it as e.g. NHibernate.Collections.**Generic.OrderedSet. We will >>> have no remaining dependency on Iesi.Collections. But some users prefer to >>> avoid referencing NHibernate types directly from e.g. domain logic. >>> >>> >>> Option 2 >>> Do a rework of Iesi.Collections targeting .Net 4 with breaking changes: >>> Remove all classes now covered by the BCL. Remaining classes (such as >>> OrderedSet) would have their interfaces updated to match .Net 4 interfaces. >>> The current version is likely to be cumbersome in combination with .Net4 >>> anyway, due to naming conflicts. This would be similar to what C5 did: >>> http://www.itu.dk/research/c5/ and http://www.itu.dk/research/c5/** >>> c5-rasmus-nielsen-2011-05-25.**pdf<http://www.itu.dk/research/c5/c5-rasmus-nielsen-2011-05-25.pdf> >>> >>> >>> What do you think? >>> >>> >>> /Oskar >>> >>> >>> > > > -- > Regards, > > Maximilian Haru Raditya > -- Regards, Maximilian Haru Raditya
