Keep in mind, this post is not focused on DSL topics (one any developer cannot really afford to miss now), so one could debate the merits of the link I make. My argument is this:

My definition of a DSL is very simply :

A Domain Specific Language is a way, typically using a combination of visual and textual methods, or just textual, to solve a limited but typically non-trivial set of problems. It is typically a smaller stand-alone ‘language’ or language-extension to a larger more horizontal language such as C# (the point I make here is C# has evolved to allow you to expand C# with DSLs you write in C#. This is very different the the DSL Toolkit and I have never had this opinion until I finally got to be immersed deeply in functional style programming enhancements to C# and the ease of extending just about any API with extensions..

I continue the discussion of what a DSL is here. I will be adding to this section of the site over time but if you just want the listed info, no need to go on a tangent now.

Now that new .NET 3.5 C# 3.0 features are allowing us to make the Framework API of .NET work in ways not present ‘out of the box’ the scope of what is possible can be deep and broad.

Part 1 : The DSL Perspective – A Real Example

I’ll use a project we are working on now, which is quite specifically aimed to

• Minimize the configuration overhead of using an Inversion of Control container
• Provide the benefit of ‘provider/container’ independence
• Allow the consumer to change ‘container provider’ vendors with a simple change in ‘meta configuration’

In other words, we are trying to create an abstraction on top of an abstraction, as we believe this particular area is now mature enough (and indeed this is how software engineering historically more then not progresses over time) to do so.

This project has no intention of BEING an inversion of control container nor a dependency injector, rather its aim is to allow people to make use of these critical concepts in much easier ways while eliminating hesitation related to provider lock-in.

It’s no secret we are massive fans of the work of the Castle Project and they are indeed the first ‘plug-in’ adapter we are on schedule to deliver. However the architecture (something this post is NOT trying to explain) of our solution models the DOMAIN of this area, and is not specific to any particular offering (although to be blunt I would say if any bias existed it would be from the conceptual framework that exists now in the Windsor Container/MicroKernal trunk).

A domain specific example

In the area of ASP.NET one technique for loading our solution into memory is via the IHttpModule implementation we provide. Here is what the custom global.asax.cs code looks like:

public abstract class IntegrationPoint : HttpApplication, IDomainApplication {

private static IZeroConfigDI _container;

/// <summary>
/// Executes custom initialization code after
/// all event handler
/// modules have been added.
/// Also acquire a reference to the HttpModule
/// for IoC / DI if present as a module
/// </summary>
 public override void Init() {        

The interesting areas which are not provided by Microsoft include:

1. IDomainApplication interface
2. IZeriConfigDI Interface static reference
3. Modules.GetIoCModule()

The first two have more to do with our solution then the topic of this post, so I’ll focus on #3.

As this code is inside the HttpApplication, we have access to the Modules property which is read-only. Here is the documentation:

Your first reaction if your familiar with this collection is that it does not have anything even close to the GetIoCModule() method we are calling above.

Indeed this is our ‘domain specific’ extension to the .NET Framework API (one of many for this solution).

Here is the implementation of this ‘DSL’ extension:

/// <summary>
/// Provides ‘DSL specific’ extensions to the ASP.NET environment for
/// the IoC Zero Config environment which is not new (after all this becomes a static)
/// </summary>
/// The entire point for extension methods is ‘Fluency in API’ as it allows ‘shorthand’ code

public static class ZeroConfigInstanceResolver {

private const string ZeroConfigTypeString = "IoCConfigModule.IHttpModel";

 /// <summary>
/// Gets the IZeroConfigDI reference
/// (using domain specific logic and the 
/// generic logic extending the container)
/// </summary>
/// <param name="container">The container.</param>
/// <returns></returns>

public static IZeroConfigDI GetIoCModule(this HttpModuleCollection container) {

                        return
                              container.FindInstance(
                                () =>
                                        container.Get(ZeroConfigTypeString)
                                                    as IZeroConfigDI);

}

As you can see above we are very specific in our intent to add this to the HttpModuleCollection. There is nothing that interesting above except for the method call FindInstance(Func<TResult>) off the target ‘container’. This is a peek into the non-DSL related extension that represents. You might be aware that there is no such FindInstance available off the HttpModuleCollection.

One of our many goals in creating a fluent, easily used API is reducing complexity and providing very maintainable code. Here you can see the Lambada expression required to locate our service is hidden from the developer completely, yet this code is not a ‘one-off’ as we have provided both a DSL level extension in concert with a far more generic extension.

Part 2: Extending the Horizontal to Empower the Domain Specific

In looking at the HttpModuleCollection, and in our desire to facilitate other sources of resolving our module, it inherits from the abstract parent NameObjectCollectionBase.

Here is the definition of what inherits from this abstract parent:

The issue arises as this abstract base leaves it up to its concrete implementer to provide the indexer (or say Get() method) to access the object desired. Therefore a nice way to enhance this abstract type to work across all of the children is to literally pass in the method to resolve the object desired.

Part 3 : The Generic Extension

Here is the trivial extension method used to ‘open up’ the NameObjectCollectionBase and which is used above:

/// <summary>
/// Finds the instance in the NameObjectCollectionBase
/// using the Functor
/// </summary>
/// <typeparam name="TContainer">The type of the container.</typeparam>
/// <typeparam name="TResult">The type of the result.</typeparam>
/// <param name="container">The container.</param>
/// <param name="finder">The finder.</param>
/// <returns></returns>
public static TResult FindInstance<TContainer, TResult>
       (this TContainer container, Func<TResult> finder)
              where TContainer : NameObjectCollectionBase where TResult : class {

                    return finder();

}

Since we cannot abstract up the get method, we take a page from Functional Programming and literally pass in the code to execute (which we do above).

A common pattern is to expose methods like the above, but add additional versions that allow more parameters into the Func<TResult>. This is well covered well by many of the Linq references and books available.

Part 4: How this allows us to embrace deep/wide change

A simplistic example is supporting the acquisitions of our target reference (IZeroConfigDI) if it is set as ApplicationState or as an IHttpModule. We could make the design decision to allow our find method to reside literally as an extension method of our HttpApplication (and indeed this turns out to be a reasonable choice as the valid inheritors from NameObjectCollectionBase are sealed and therefore invalid as generic constraints). Here is one approach (not ideal and not our final code but this illustrates the point.) Why not offer your optimized solution?

CODE:

public abstract class IntegrationPoint : HttpApplication, IDomainApplication {

private static IZeroConfigDI _container;

/// <summary>
/// Executes custom initialization code after
/// all event handler
/// modules have been added.
/// Also acquire a reference to the HttpModule
/// or Application State
/// for IoC / DI if present
/// </summary>
public override void Init() {

                  _container = this.GetIoCModule(); base.Init();

}

And the extension on HttpApplication:

public static class ZeroConfigInstanceResolver {

private const string ZeroConfigTypeString = "IoCConfigModule.IHttpModel";

/// <summary>
/// Gets the IZeroConfigDI reference if possible (null if not found)
/// using domain specific logic and the
/// generic logic extending the container.
/// </summary>
/// <param name="container">The container.</param>
/// <returns></returns>
public static IZeroConfigDI GetIoCModule(this HttpApplication container) {

                       var modules = container.Modules;
                       var applicationState = container.Application; 
                     

                        var resultVar = modules.ToInstance(
                                   () => modules.Get(ZeroConfigTypeString)
                         )
                        ?? 
                        applicationState.ToInstance(
                                   () => applicationState.Get(ZeroConfigTypeString)
                         );

                       return resultVar as IZeroConfigDI;

}

No change is required on the extension to the FindInstance extension.

Can you see how the above can be improved?

We expand this to make the ‘rule for finding the IZeroConfigDI external. To be specific, above we have a business rule implemented that we typically would not want ‘hard coded’. In fact more then not all things considered we want this. So we do the4 following:

• Determine the Delegate signature for the business rule.
• For the above, we need as input (at a minimum) an HttpApplication instance as that is the container for the models and state, and those two items lack a shared interface or base (or we could use that).
• The signature returns (in all cases) an instance cast where it implement IZeroConfigDI to resolve this business rule.
• Therefore the business rule signature is Func<HttpApplication ,IZeroConfigDI>

The world’s most common extension method and an attempt at a definitive version.

In this post I’ll be digging deeper into doing things I’ve always wanted to have in .NET yet didn’t. For example, I know I am not alone in wanting an IList (be it an IList<T> or a simple non-generic IList) to provide me a .foreach method as you get in a List<T>). This is just one of many things we address here (and more).

From the concrete to the abstract

I was having problems with entries in my path environmental variable, and I wanted an easy way to flag bad entries and also allow me to move the entries in the list up or down easily. This was made apparent by my use of a tool called ‘Dependency Walker’. It’s hard to live without but that’s another post. See the screen shot below:

Click here to go to ‘Dependency Walker’

Test to Code

    /// <summary>
    /// Unit Test to Validate that the logic related to     /// 'show combined extensions using paths' is functioning
    /// </summary>
    /// Documentation Created 5/22/2008
    [Test]
    public void shouldShowCombinedExtensionsUsingPaths()
    {
        var _directoriesInPath = EnvironmentVariableTarget.             Process.GetParsedValues("PATH");

        Assert.That(_directoriesInPath, Is.                TypeOf(typeof(String[])));
        Assert.IsTrue(!_directoriesInPath.IsNullOrEmpty());

        _directoriesInPath.ForEach(
            x =>
            {
                if (!Directory.Exists(x))
                    Console.WriteLine("MIssing Directory! " + x);
            });
    }

Above is the test (that also works). Before I launch into why this is interesting, what looks different?

1) EnvironmentVariableTarget : This is Microsoft’s type not mine. It’s the enum used to specify the target search on the environmentals.

2) _directoriesInPath : This is a string[] as you can see from the Assertion. But how does it support ForEach?

3) GetParsedValues() : What is that exactly?

*** As this is so common I decided to try to craft a definitive version of ForEach that would work across non-generic collections, generic collection, and specific type specification on the targeted items in the collection for generics .  ***

In order to enable ForEach behavior I needed to this code which is by far the most common extension method in all the C# 3.0 code alive today.

    /// <summary>
    /// Requires generic IEnumerable and is most common now
    /// </summary>
    /// <typeparam name="TContainedType">The type of the contained type.</typeparam>
    /// <param name="baseEnum">The base enum.</param>
    /// <param name="actionPerform">The action perform.</param>
    /// <returns></returns>
    /// Documentation Created 7/20/2008
    public static IEnumerable<TContainedType> ForEach<TContainedType>(
           this IEnumerable<TContainedType> baseEnum,
               Action<TContainedType> actionPerform) {

        return ForEachInner(baseEnum, actionPerform);
    }

    /// <summary>
    /// The most explicit case
    /// </summary>
    /// <typeparam name="TBase">The type of the base.</typeparam>
    /// <typeparam name="TContainedType">The type of the contained type.</typeparam>
    /// <param name="baselineEnumerable">The baseline enumerable.</param>
    /// <param name="actionPerform">The action perform.</param>
    /// <returns></returns>
    /// Documentation Created 7/20/2008
    public static IEnumerable<TContainedType> ForEach<TBase, TContainedType>(
              this TBase baselineEnumerable, Action<TContainedType> actionPerform)
                   where TBase : IEnumerable {

        return ForEachInner(baselineEnumerable.OfType<TContainedType>(), actionPerform);
    }

    /// <summary>
    /// The least restrictive case
    /// </summary>
    /// <param name="baseEnum">The base enum.</param>
    /// <param name="actionPerform">The action perform.</param>
    /// <returns></returns>
    /// Documentation Created 7/20/2008
    public static IEnumerable<Object> ForEach(this IEnumerable baseEnum,                Action<Object>  actionPerform) {

        return ForEachInner(baseEnum.OfType<Object>(), actionPerform);
    }

    /// <summary>
    /// Do the actual work
    /// </summary>
    /// <typeparam name="TContainedType">The type of the contained type.</typeparam>
    /// <param name="baseEnum">The base enum.</param>
    /// <param name="actionPerform">The action perform.</param>
    /// <returns></returns>
    /// Documentation Created 7/20/2008
    private static IEnumerable<TContainedType> ForEachInner<TContainedType>(
        IEnumerable<TContainedType> baseEnum,
                       Action<TContainedType> actionPerform) {

        var getEnumerate = baseEnum.ToList();
        getEnumerate.ForEach(actionPerform);

        return getEnumerate;
    }

Notice that anything which implements IEnumerable is caught above, regardless of what the collection.

busy developing ReSharper 4 :) Here is quick update. We are currently working on preparing ReSharper for Beta – performance, memory, overall stability and reliability. Beta should be out very soon. Then we will have

post-Beta cleanup, more stabilization for Release, fill in missing bricks found during Beta, and then … Well, overall time scope for ReSharper 4 release is about a month. Thank you for your patience, we really appreciate your participation in our early access program! We are doing our best to deliver smart and quality product. And while we are here, what is *single* most important thing you want to be fixed/changed before release?

Sincerely,

Ilya Ryzhenkov

JetBrains, Inc

http://www.jetbrains.com “Develop with pleasure!”

With .NET 3.5 and C# 3.0 released now, it was time for an update. As part of the update, I also improved the API a little bit. Usage now is:

MethodInfo toString = Reflect<object>.GetMethod(x => x.ToString());

The renamed Reflect<TTarget> class receives the type you want to reflect as a generic parameter. Then you can use GetMethod, GetField or GetProperty.

Other examples:

MethodInfo clone = Reflect<ICloneable>.GetMethod(x => x.Clone());
PropertyInfo prop = Reflect<AppDomain>.GetProperty(x => x.BaseDirectory);
FieldInfo field = Reflect<Mock>.GetField(x => x.PublicField);

Working principle is the same: the lambda you pass to the methods is actually an expression

which I analyze to retrieve the underlying reflection object that is already exposed by the LINQ Expression API. For example, once you get to a MethodCallExpression, you can get the method being called through its Method property:

((MethodCallExpression)lambda.Body).Method;

It’s interesting to see how this works actually, and what’s the compiler generating for those lambda expressions invoking methods.

In Reflector, the following C# code:

MethodInfo clone = Reflect<ICloneable>.GetMethod(x => x.Clone());

is decompiled as (indented for readability):

ParameterExpression CS$0$0000;
MethodInfo clone = Reflect<ICloneable>.GetMethod(
Expression.Lambda<Action<ICloneable>>(Expression.Call(CS$0$0000 =
Expression.Parameter(typeof(ICloneable), "x"),
 (MethodInfo) methodof(ICloneable.Clone), new Expression[0] ),
new ParameterExpression[] { CS$0$0000 }  ));

Note how the MethodInfo is retrieved directly from the interface by using a methodof operator. It’s not a valid C# keyword, but given that Lutz Roeder works for Microsoft (not on the C# team, though), let’s hope it will get eventually in the language :).

That methodof translation is actually the conversion from the following two IL lines:

L_0017: ldtoken instance object [mscorlib]System.ICloneable::Clone()L_001c: call class
 [mscorlib]System.Reflection.MethodBase

[mscorlib]System.Reflection.MethodBase::GetMethodFromHandle(valuetype

[mscorlib]System.RuntimeMethodHandle)

ldtoken is the key there, let’s hope it gets promoted to C# in some way eventually.

Anyway, since I wrote my original article, I realized through Ayende’s blog that you can also do static reflection without LINQ. It only works for methods though, and you cannot use the lambda syntax because it results in method infos that are actually from a compiler-generated type (the one that contains the closures too if any).

As I’m so in love with the lambda syntax, I’ll keep my implementation based on expression trees instead of delegates.

It’s released now as part of Clarius Labs projects. Get the source and have fun!”

Daniel Cazzulino’s Blog : Statically-typed reflection with LINQ