Consider, for example, the method:
public static Attribute GetCustomAttribute(this ParameterInfo element, Type attributeType);
defined in System.Reflection.CustomAttributeExtensions
Wouldn't it make more sense to define instead:
public static T GetCustomAttribute<T>(this ParameterInfo element, T attributeType) where T : Attribute;
And save the casting?
The non-generic method of retrieving custom attribute is from the old .NET days when generics weren't implemented.
For current and future coding, you can take advantage of CustomAttributeExtensions.GetCustomAttributes<T> - if you're coding using .NET 4.5 version and above -.
Sadly - or maybe actually - software has a sequential evolution. I mean, there was a time where generic weren't with us (.NET 1.0 and 1.1), and there's a lot of code base that's inherited from early .NET versions, and because of framework team prioritzation it seems like not every method that would be better using a generic parameter(s) has been already implemented.
About inherited code
#BenRobinson said in some comment here bellow:
The point I was making was that these extension methods were added in
.net 4.5 (all of them not just the generic ones) and extension methods
were added after generics so non generic extension methods of any kind
have nothing to do with backwards compatibility with .net 1.0/1.1.
I'm adding this to avoid confusion: don't understand inherited code in terms of Microsoft not changing the non-generic code base because of backwards compatibility with third-party code.
Actually, I'm pointing out that current .NET version itself has a lot of code inherited from early .NET versions, either if the intention of Microsoft is maintaining backwards compatibility with third-party code or not.
I assume or guess that .NET Framework Team has prioritized new base class library (BCL) and satellite frameworks additions and some of members coming from pre-generics era are still as is because the change isn't worth the effort, or we could discuss if it's worth the effort and they did design decision mistakes, but StackOverflow isn't a discussion board, is it?
There is indeed a an overload that is equivalent to your example, GetCustomAttribute<T>(ParameterInfo), however to call this method without nasty reflection, you need to know the type of T at compile time. If you only know the type of T at run time then the equivalent method is GetCustomAttribute(ParameterInfo, Type)
Generics was added to the C# language in version 2. I believe that attributes was in the language at version 1 or 1.1 (can't remember which, I think it was in version 1 but I could be wrong).
This means that even though they would have saved a lot of unnecessary casting by changing all methods to use generics instead, they could have broken backwards compatability. And breaking backwards compatability is bad™.
Edit:
Also, I just thought about one more reason.
If you are writing reflection code it's often quite a hassle to call a generic method via reflection (C# has a really stupid api for doing so...) so if you are writing reflection code then using the non-generic version is in many cases much easier than using the generic one.
Edit again:
Damn, Ben Robinson beat me to the reflection point by a minute! :)
I am trying to design a library in F#. The library should be friendly for use from both F# and C#.
And this is where I'm stuck a little bit. I can make it F# friendly, or I can make it C# friendly, but the problem is how to make it friendly for both.
Here is an example. Imagine I have the following function in F#:
let compose (f: 'T -> 'TResult) (a : 'TResult -> unit) = f >> a
This is perfectly usable from F#:
let useComposeInFsharp() =
let composite = compose (fun item -> item.ToString) (fun item -> printfn "%A" item)
composite "foo"
composite "bar"
In C#, the compose function has the following signature:
FSharpFunc<T, Unit> compose<T, TResult>(FSharpFunc<T, TResult> f, FSharpFunc<TResult, Unit> a);
But of course, I don't want FSharpFunc in the signature, what I want is Func and Action instead, like this:
Action<T> compose2<T, TResult>(Func<T, TResult> f, Action<TResult> a);
To achieve this, I can create compose2 function like this:
let compose2 (f: Func<'T, 'TResult>) (a : Action<'TResult> ) =
new Action<'T>(f.Invoke >> a.Invoke)
Now, this is perfectly usable in C#:
void UseCompose2FromCs()
{
compose2((string s) => s.ToUpper(), Console.WriteLine);
}
But now we have a problem using compose2 from F#! Now I have to wrap all standard F# funs into Func and Action, like this:
let useCompose2InFsharp() =
let f = Func<_,_>(fun item -> item.ToString())
let a = Action<_>(fun item -> printfn "%A" item)
let composite2 = compose2 f a
composite2.Invoke "foo"
composite2.Invoke "bar"
The question: How can we achieve first-class experience for the library written in F# for both F# and C# users?
So far, I couldn't come up with anything better than these two approaches:
Two separate assemblies: one targeted to F# users, and the second to C# users.
One assembly but different namespaces: one for F# users, and the second for C# users.
For the first approach, I would do something like this:
Create a F# project, call it FooBarFs and compile it into FooBarFs.dll.
Target the library purely to F# users.
Hide everything unnecessary from the .fsi files.
Create another F# project, call if FooBarCs and compile it into FooFar.dll
Reuse the first F# project at the source level.
Create .fsi file which hides everything from that project.
Create .fsi file which exposes the library in C# way, using C# idioms for name, namespaces, etc.
Create wrappers that delegate to the core library, doing the conversion where necessary.
I think the second approach with the namespaces can be confusing to the users, but then you have one assembly.
The question: None of these are ideal, perhaps I am missing some kind of compiler flag/switch/attribute
or some kind of trick and there is a better way of doing this?
The question: has anyone else tried to achieve something similar and if so how did you do it?
EDIT: to clarify, the question is not only about functions and delegates but the overall experience of a C# user with an F# library. This includes namespaces, naming conventions, idioms and suchlike that are native to C#. Basically, a C# user shouldn't be able to detect that the library was authored in F#. And vice versa, an F# user should feel like dealing with a C# library.
EDIT 2:
I can see from the answers and comments so far that my question lacks the necessary depth,
perhaps mostly due to use of only one example where interoperability issues between F# and C#
arise, the issue of function values. I think this is the most obvious example and so this
led me to use it to ask the question, but by the same token gave the impression that this is
the only issue I am concerned with.
Let me provide more concrete examples. I have read through the most excellent
F# Component Design Guidelines
document (many thanks #gradbot for this!). The guidelines in the document, if used, do address
some of the issues but not all.
The document is split into two main parts: 1) guidelines for targeting F# users; and 2) guidelines for
targeting C# users. Nowhere does it even attempt to pretend that it is possible to have a uniform
approach, which exactly echoes my question: we can target F#, we can target C#, but what is the
practical solution for targeting both?
To remind, the goal is to have a library authored in F#, and which can be used idiomatically from
both F# and C# languages.
The keyword here is idiomatic. The issue is not the general interoperability where it is just possible
to use libraries in different languages.
Now to the examples, which I take straight from
F# Component Design Guidelines.
Modules+functions (F#) vs Namespaces+Types+functions
F#: Do use namespaces or modules to contain your types and modules.
The idiomatic use is to place functions in modules, e.g.:
// library
module Foo
let bar() = ...
let zoo() = ...
// Use from F#
open Foo
bar()
zoo()
C#: Do use namespaces, types and members as the primary organizational structure for your
components (as opposed to modules), for vanilla .NET APIs.
This is incompatible with the F# guideline, and the example would need
to be re-written to fit the C# users:
[<AbstractClass; Sealed>]
type Foo =
static member bar() = ...
static member zoo() = ...
By doing so though, we break the idiomatic use from F# because
we can no longer use bar and zoo without prefixing it with Foo.
Use of tuples
F#: Do use tuples when appropriate for return values.
C#: Avoid using tuples as return values in vanilla .NET APIs.
Async
F#: Do use Async for async programming at F# API boundaries.
C#: Do expose asynchronous operations using either the .NET asynchronous programming model
(BeginFoo, EndFoo), or as methods returning .NET tasks (Task), rather than as F# Async
objects.
Use of Option
F#: Consider using option values for return types instead of raising exceptions (for F#-facing code).
Consider using the TryGetValue pattern instead of returning F# option values (option) in vanilla
.NET APIs, and prefer method overloading over taking F# option values as arguments.
Discriminated unions
F#: Do use discriminated unions as an alternative to class hierarchies for creating tree-structured data
C#: no specific guidelines for this, but the concept of discriminated unions is foreign to C#
Curried functions
F#: curried functions are idiomatic for F#
C#: Do not use currying of parameters in vanilla .NET APIs.
Checking for null values
F#: this is not idiomatic for F#
C#: Consider checking for null values on vanilla .NET API boundaries.
Use of F# types list, map, set, etc
F#: it is idiomatic to use these in F#
C#: Consider using the .NET collection interface types IEnumerable and IDictionary
for parameters and return values in vanilla .NET APIs. (i.e. do not use F# list, map, set)
Function types (the obvious one)
F#: use of F# functions as values is idiomatic for F#, obviously
C#: Do use .NET delegate types in preference to F# function types in vanilla .NET APIs.
I think these should be sufficient to demonstrate the nature of my question.
Incidentally, the guidelines also have a partial answer:
... a common implementation strategy when developing higher-order
methods for vanilla .NET libraries is to author all the implementation using F# function types, and
then create the public API using delegates as a thin façade atop the actual F# implementation.
To summarise.
There is one definite answer: there are no compiler tricks that I missed.
As per the guidelines doc, it seems that authoring for F# first and then creating
a facade wrapper for .NET is a reasonable strategy.
The question then remains regarding the practical implementation of this:
Separate assemblies? or
Different namespaces?
If my interpretation is correct, Tomas suggests that using separate namespaces should
be sufficient, and should be an acceptable solution.
I think I will agree with that given that the choice of namespaces is such that it
does not surprise or confuse the .NET/C# users, which means that the namespace
for them should probably look like it is the primary namespace for them. The
F# users will have to take the burden of choosing F#-specific namespace.
For example:
FSharp.Foo.Bar -> namespace for F# facing the library
Foo.Bar -> namespace for .NET wrapper, idiomatic for C#
Daniel already explained how to define a C#-friendly version of the F# function that you wrote, so I'll add some higher-level comments. First of all, you should read the F# Component Design Guidelines (referenced already by gradbot). This is a document that explains how to design F# and .NET libraries using F# and it should answer many of your questions.
When using F#, there are basically two kinds of libraries you can write:
F# library is designed to be used only from F#, so it's public interface is written in a functional style (using F# function types, tuples, discriminated unions etc.)
.NET library is designed to be used from any .NET language (including C# and F#) and it typically follows .NET object-oriented style. This means that you'll expose most of the functionality as classes with method (and sometimes extension methods or static methods, but mostly the code should be written in the OO design).
In your question, you're asking how to expose function composition as a .NET library, but I think that functions like your compose are too low level concepts from the .NET library point of view. You can expose them as methods working with Func and Action, but that probably isn't how you would design a normal .NET library in the first place (perhaps you'd use the Builder pattern instead or something like that).
In some cases (i.e. when designing numerical libraries that do not really fit well with the .NET library style), it makes a good sense to design a library that mixes both F# and .NET styles in a single library. The best way to do this is to have normal F# (or normal .NET) API and then provide wrappers for natural use in the other style. The wrappers can be in a separate namespace (like MyLibrary.FSharp and MyLibrary).
In your example, you could leave the F# implementation in MyLibrary.FSharp and then add .NET (C#-friendly) wrappers (similar to code that Daniel posted) in the MyLibrary namespace as static method of some class. But again, .NET library would probably have more specific API than function composition.
You only have to wrap function values (partially-applied functions, etc) with Func or Action, the rest are converted automatically. For example:
type A(arg) =
member x.Invoke(f: Func<_,_>) = f.Invoke(arg)
let a = A(1)
a.Invoke(fun i -> i + 1)
So it makes sense to use Func/Action where applicable. Does this eliminate your concerns? I think your proposed solutions are overly-complicated. You can write your entire library in F# and use it pain-free from F# and C# (I do it all the time).
Also, F# is more flexible than C# in terms of interoperability so it's generally best to follow traditional .NET style when this is a concern.
EDIT
The work required to make two public interfaces in separate namespaces, I think, is only warranted when they are complementary or the F# functionality is not usable from C# (such as inlined functions, which depend on F#-specific metadata).
Taking your points in turn:
Module + let bindings and constructor-less type + static members appear exactly the same in C#, so go with modules if you can. You can use CompiledNameAttribute to give members C#-friendly names.
I may be wrong, but my guess is that the Component Guidelines were written prior to System.Tuple being added to the framework. (In earlier versions F# defined it's own tuple type.) It's since become more acceptable to use Tuple in a public interface for trivial types.
This is where I think you have do things the C# way because F# plays well with Task but C# doesn't play well with Async. You can use async internally then call Async.StartAsTask before returning from a public method.
Embrace of null may be the single biggest drawback when developing an API for use from C#. In the past, I tried all kinds of tricks to avoid considering null in internal F# code but, in the end, it was best to mark types with public constructors with [<AllowNullLiteral>] and check args for null. It's no worse than C# in this respect.
Discriminated unions are generally compiled to class hierarchies but always have a relatively friendly representation in C#. I would say, mark them with [<AllowNullLiteral>] and use them.
Curried functions produce function values, which shouldn't be used.
I found it was better to embrace null than to depend on it being caught at the public interface and ignore it internally. YMMV.
It makes a lot of sense to use list/map/set internally. They can all be exposed through the public interface as IEnumerable<_>. Also, seq, dict, and Seq.readonly are frequently useful.
See #6.
Which strategy you take depends on the type and size of your library but, in my experience, finding the sweet spot between F# and C# required less work—in the long run—than creating separate APIs.
Although it probably would be an overkill, you could consider writing an application using Mono.Cecil (it has awesome support on the mailing list) that would automate the conversion on the IL level. For example, you implement your assembly in F#, using the F#-style public API, then the tool would generate a C#-friendly wrapper over it.
For instance, in F# you would obviously use option<'T> (None, specifically) instead of using null like in C#. Writing a wrapper generator for this scenario should be fairly easy: the wrapper method would invoke the original method: if it's return value was Some x, then return x, otherwise return null.
You would need to handle the case when T is a value type, i.e. non-nullable; you would have to wrap the return value of the wrapper method into Nullable<T>, which makes it a bit painful.
Again, I'm quite certain that it would pay off to write such a tool in your scenario, maybe except if you'll be working on this such library (usable seamlessly from F# and C# both) regularly. In any case, I think it would be an interesting experiment, one that I might even explore sometime.
Draft F# Component Design Guidelines
(August 2010)
Overview This document looks at some of the issues related to F# component design and coding. In particular, it covers:
Guidelines for designing “vanilla” .NET libraries for use from any .NET language.
Guidelines for F#-to-F# libraries and F# implementation code.
Suggestions on coding conventions for F# implementation code
I've recently come across the ConditionalWeakTable<TKey,TValue> class in my search for an IDictionary which uses weak references, as suggested in answers here and here.
There is a definitive MSDN article which introduced the class and which states:
You can find the class ... in the System.Runtime.CompilerServices namespace. It’s in CompilerServices because it’s not a general-purpose dictionary type: we intend for it to only be used by compiler writers.
and later again:
...the conditional weak table is not intended to be a general purpose collection... But if you’re writing a .NET language of your own and need to expose the ability to attach properties to objects you should definitely look into the Conditional Weak Table.
In line with this, the MSDN entry description of the class reads:
Enables compilers to dynamically attach object fields to managed objects.
So obviously it was originally created for a very specific purpose - to help the DLR, and the System.Runtime.CompilerServices namespace embodies this. But it seems to have found a much wider use than that - even within the CLR. If I search for references of ConditionalWeakTable in ILSpy, for example, I can see that is used in the MEF class CatalogExportProvider and in the internal WPF DataGridHelper class, amongst others.
My question is whether it is okay to use ConditionalWeakTable outside of compiler writing and language tools, and whether there is any risk in doing so in terms of incurring additional overhead or of the implementation changing significantly in future .NET versions. (Or should it be avoided and a custom implementation like this one be used instead).
There is also further reading here, here and here about how the ConditionalWeakTable makes use of a hidden CLR implementation of ephemerons (via System.Runtime.Compiler.Services. DependentHandle) to deal with the problem of cycles between keys and values, and how this cannot easily be accomplished in a custom manner.
I don't see anything wrong with using ConditionalWeakTable. If you need ephemerons, you pretty much have no other choice.
I don't think future .NET versions will be a problem - even if only compilers would use this class, Microsoft still couldn't change it without breaking compatibility with existing binaries.
As for overhead - there certainly will be overhead compared to a normal Dictionary. Having many DependentHandles probably will be expensive similarly to how many WeakReferences are more expensive than normal references (the GC has to do additional work to scan them to see if they need to be nulled out). But that's not a problem unless you have lots (several million) of entries.
I'm working on improving my skills in other languages, coming from using c++ as my primary programming language. My current project is hammering down C#.net, as I have heard it is a good in-between language for one who knows both c++ and VB.net.
Typically when working with an unknown number of elements in c++ I would declare my variable as a vector and just go from there. Vectors don't seem to exist in c#, and in my current program I have been using arraylists instead, but I'm starting to wonder if it's a good habit to use arraylists as I read somewhere that it was a carryover from .net 1.0
Long question short- what is the most commonly used listing type for c#?
If you target pre .NET 2.0 versions, use ArrayList
If you target .NET 2.0+ then use generic type List<T>
You may need to find replacements for other C++ standard containers, so here is possible mapping of C++ to .NET 2.0+ similar types or equivalents:
std::vector - List<T>
std::list - LinkedList<T>
std::map - Dictionary<K, V>
std::set - HashSet<T>
std::multimap - Dictionary<K, List<V>>
I would recommend you explore the System.Collections namespace, especially the System.Collections.Generics set of objects. The built-in functionality can be strongly typed across the various Lists, Dictionaries and NameValueCollections to provide you with a wide range of capabilities. They are also extendable so if they don't do EXACTLY what you need, you just extend them and add the new functionality.
That'd be List<T>, I suppose. ArrayList is the non-generic type and—as you correctly observed—a leftover from the .NET 1 times. Starting with .NET 2 you can use Generics and therefore List<T>.
Short answer: List<T>. You can find the docs here.
I'm working on a something related to roughset right now. The project uses alot of sets operation and manipulation. I've been using string operations as a stop gap measure for set operation. It has worked fine until we need to process some ungodly amount of data ( 500,000 records with about 40+ columns each ) through the algorithm.
I know that there is no set data structure in .net 2.0(2.0 was the latest when I started the project) I want to know if there is any library that offer fast set operation in .net c# or if 3.5 has added native set data structure.
Thanks .
.NET 3.5 already has a native set data type: HashSet. You might also want to look at HashSet and LINQ set operators for the operations.
In .NET 1.0, there was a third party Set data type: Iesi.Collections which was extended with .NET 2.0 generics with Iesi.Collections.Generic.
You might want to try and look at all of them to see which one would benefit you the most. :)
LINQ supports some set operations. See LINQ 101 page for examples.
Also there is a class HashSet (.NET 3.5)
Here is Microsoft guidelines for set operations in .NET:
HashSet and LINQ Set Operations
List of set operations supported by HasSet class:
HashSet Collection Type
Update: This is for .Net 2.0. For .Net 3.5, refer posts by aku, Jon..
This is a good reference for efficiently representing sets in .Net.
It may be worth taking a look at C5, it's a generic collection library for .NET which includes sets.
Note that I haven't looked into it much, but it seems to be a pretty fantastic collection library.
Try HashSet in .NET 3.5.
This page from a member of the .NET BCL team has some good information on the intent of HashSet
I have been abusing the Dictionary class in .NET 2.0 as a set:
private object dummy = "ok";
public void Add(object el) {
dict[el] = dummy;
}
public bool Contains(object el) {
return dict.ContainsKey(el);
}
You can use Linq to Objects in C# 3.0.
You ever think about sing F#? This seems like a job for a functional programming language.
You should take a look at C5 Generic Collection Library. This library is a systematic approach to fix holes in .NET class library by providing missing structures, as well as replacing existing ones with set of well designed interfaces and generic classes.
Among others, there is HashSet<T> - generic Set class based on linear hashing.