Backport .NET 4.5 readonly collection interfaces

[mausch]

IReadOnlyCollection: http://msdn.microsoft.com/en-us/library/hh881542.aspx

IReadOnlyList : http://msdn.microsoft.com/en-us/library/hh192385(v=vs.110).aspx

IReadOnlyDictionary: http://msdn.microsoft.com/en-us/library/hh136548(v=vs.110).aspx

ifdef it to ensure they don't get compiled on .NET 4.5.

Adapters to expose:

• F# list as IReadOnlyList
• F# map as IReadOnlyDictionary
• IDictionary as IReadOnlyDictionary
• IList as IReadOnlyList

TryFind for IReadOnlyList and IReadOnlyDictionary

[mausch]

Problem: F# doesn't have variance annotations.
Solution 1: Write the interfaces in a separate C# project, then ILMerge with FSharpx.Core.
Solution 2: Write a little program using Cecil to make the interfaces covariant post-compilation.

[mausch]

Solution 2 done in https://github.com/mausch/VariantInterfaces

[mausch]

Ongoing work in https://github.com/mausch/fsharpx/tree/readonlycollections

[mausch]

Another problem: F# doesn't support TypeForwardedToAttribute, necessary for backwards compatibility in the .NET 4.5 build of FSharpx. http://fpish.net/topic/Some/0/75803
Solutions are similar as before:
Solution 1: Write the interfaces in a separate C# project, then ILMerge with FSharpx.Core.
Solution 2: Write a little program using Cecil to add type forwarding to the assembly. Note that it's not as easy as adding the assembly attribute, it needs to emit the right IL, see http://community.bartdesmet.net/blogs/bart/archive/2006/09/30/4479.aspx

[mausch]

Wrote interfaces and adapters in C# https://github.com/mausch/ReadOnlyCollections .
Now I'm not sure if this should be released separately and/or how FSharpx would use/merge/depend on this.

[forki]

Can we ILMerge this stuff into FSharpx?

[mausch]

Yup, but I started considering releasing it separately: one package only for the interfaces (ReadOnlyCollectionInterfaces), another for the adapters (ReadOnlyCollectionExtensions). The interfaces package would only reflect what's already there in .NET 4.5. So if you don't like those adapters and want to write your own, you could still take a dependency on ReadOnlyCollectionInterfaces. Also this would probably make things more portable... e.g. I implemented ReadOnlyCollectionExtensions for .NET 2.0 via LinqBridge. Personally though I don't really care for .NET 2.0 :)

Of course, I really like FSharpx not depending on anything. But if this is merged into FSharpx and also released separately, if someone installs both they'll have a conflict. A solution around that would be to install a ReadOnlyCollectionInterfaces that only consists of forwarding types to FSharpx. But I don't know how I'd package something like that.
The easiest "solution" would be simply not to release it separately. No risk of conflict there :)
Or make FSharpx take a dependency to ReadOnlyCollectionInterfaces... but we all like FSharpx not depending on anything...

[mausch]

Including this (either by merging or depending on ReadOnlyCollectionInterfaces) would mean adding a specific target for .NET 4.5 to FSharpx (to avoid a conflict with the built-in IReadOnly* interfaces)

[mausch]

I released https://github.com/mausch/ReadOnlyCollections in two separate packages, I really think it's the easiest and most flexible approach.

From the F# / FSharpx point of view, we have a few alternatives:

• Take a dependency on https://nuget.org/packages/ReadOnlyCollectionInterfaces/ , add adapters for FSharp.Core and make FSharpx implement these interfaces. Add a .NET 4.5 build of FSharpx, which wouldn't have this dependency.
• Take a dependency on https://nuget.org/packages/ReadOnlyCollectionInterfaces/ , make FSharpx implement these interfaces. Add a .NET 4.5 build of FSharpx, which wouldn't have this dependency. Leave it to another package to provide adapters for FSharp.Core collections.
• Leave it to another package to add adapters for FSharpx collections.

[ghost]

Can we close this issue?

The dependencies this introduces just don't seem worth it - the new interfaces aren't that significant for F# programming, and adaptors can always be used instead.

[ghost]

Closing this for now to avoid the dependency management problems that would result.