actually, calling Cast<T>() on the collections is enough, although sometimes it's not obvious which type we should be casting to (i.e. InterfaceCollection needs to be casted to TypeReference), which hinders usability. I don't think it makes much sense to pick the lowest common denominator across supported platform versions, thus preventing users on newer versions of the advantages of the platform.
If you need to #ifdef around it, that's fine. If you need to branch and keep separate trees, fine too. But I wouldn't make users pay for the backwards compatibility cost via usability. Especially for a library that is external and only has a dependency on mscorlib and which is typically used in external tools (it's not part of the BCL). my 2cents :) On Sun, Jan 4, 2009 at 10:56 AM, Mark Cidade (G) <[email protected]> wrote: > > An alternative would be to add the LINQ operators to the existing > collection > types via extension methods in a separate DLL. The extension methods could > all be auto-code-generated since it's just delegating to the > System.Core.dll > methods after a Cast<T>(). > > M. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jb Evain > Sent: Sunday, January 04, 2009 7:20 AM > To: [email protected] > Subject: [mono-cecil] Re: Patch to make all Mono.Cecil collections > implement > IEnumerable<T> > > > Hey Daniel, > > On 1/4/09, Daniel Cazzulino <[email protected]> wrote: > > This enables seamless integration with all the LINQ goodness, rather than > > being forced (and usually forgetting) to invoke collection.Cast<T> on all > > collections before using them in queries. > > The issue is that the current version of Cecil is still being used on > .net 1.1 (and even on the CF 1.0). I'll maintain it this way for a > while I guess. > > > > > > -- Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471 --~--~---------~--~----~------------~-------~--~----~ -- mono-cecil -~----------~----~----~----~------~----~------~--~---
