FCL Extension

The Framework Class Library Extension project contains highly reuseable classes I find to be missing in .NET’s FCL.

Features

Generic interpolation classes (Whathecode.System.Arithmetic.Interpolation)

  • Linear and cardinal spline interpolation.
  • Supports any type by implementing a small trivial type provider for it.

Generic interval (range) class (Whathecode.System.Arithmetic.Range)

  • Support for reversed ranges, including/excluding edges.

Generic binary search (Whathecode.System.Collections.Algorithm)

Extension methods

  • Linq (Whathecode.System.Linq)
  • Generally useful methods. (Whathecode.System.Extensions)
  • To simplify using reflection (Whathecode.System.Reflection.Extensions)

WPF and MVVM utilities (Whathecode.PresentationFramework assembly)

  • Factories to simplify creation of dependency properties, notify properties and commands.
  • Reuseable generic coercion and validation handlers for dependency properties.
  • Attached mouse behavior supporting click drag operations. (Whathecode.System.Xaml.Behaviors.MouseBehavior)
  • Bind observer (view model) to any read-only properties in XAML. (Whathecode.System.Xaml.PropertyObservers)

Runtime compilation

  • More advanced delegate creation from MethodInfo and wrapping existing delegates. E.g. force downcasting arguments to the expected types. (normal and open instance delegates) During reflection this can be used when no concrete types are known, but types are known to be the correct ones. (Whathecode.System.DelegateHelper)
  • Create non (or less) generic wrapper interfaces at runtime. (Whathecode.System.Reflection.Emit.Proxy)

Generic attributes work around

  • Allows to initialize generic classes through attributes. (Whathecode.System.AbstractBehaviorAttribute)
  • E.g. this is used to attach generic handlers to properties in the dependency property factory.

Many other helper classes

  • Easier enum parsing/usage, …

Structure

The structure from the original FCL is followed as much as possible.

Assemblies

  • Whathecode.System extends on System, System.Core and WindowsBase.
  • Whathecode.PresentationFramework extends on PresentationCore and PresentationFramework.

Namespaces

  • Helper classes are contained within the corresponding namespace. E.g. The helper class for System.Diagnostics.Process is located in Whathecode.System.Diagnostics.ProcessHelper.
  • APIs are located in the relevant namespace. E.g. An abstract input controller is located in Whathecode.System.Windows.Input.InputController.
  • Linq extensions are located in Whathecode.System.Linq.
  • Extension methods are placed in an Extension namespace in the relevant namespace. E.g. general extensions are located in Whathecode.System.Extensions, while extension methods to help with reflection are located in Whathecode.System.Reflection.Extensions.
  • Unit tests are placed in a Tests namespace in the relevant namespace. MSTest is used. These tests also serve as examples.
  • Aspects are placed in an Aspects namespace in the relevant namespace. In order to use them PostSharp is required, but no other code is dependent on those projects.

The library also contains unproven toy classes, which I still have to experiment with to judge their usefulness. They are located within *.Experimental namespaces.

Some classes do runtime code compilation which was made possible thanks to the excellent RunSharp library of Stefan Simik. It really simplifies Reflection.Emit.

License

Copyright (c) 2011 Steven Jeuris
The library is distributed under the terms of the MIT license.

Advertisements
  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: