Ayende @ Rahien

Oren Eini aka Ayende Rahien CEO of Hibernating Rhinos LTD, which develops RavenDB, a NoSQL Open Source Document Database.

You can reach me by:

oren@ravendb.net

+972 52-548-6969

, @ Q j

Posts: 6,888 | Comments: 49,278

filter by tags archive
time to read 4 min | 619 words

I got the chance to get an early CTP of Visual Studio 2010. 

image

This is the post I use to record my first impressions. There is no order to this post, it is just impressions jotted down as I see them.

We seem to have a new start page:

image

Following the MS & OSS new approach, one of the samples is Dinner Now using Lucene, which is the first project that I found to test.

TFS is still broken:

image

I really don't like to see this kind of issues in a source control system. It means that it cannot be trusted.

image

Looks like we have something new here. On first impression, it looks like we have UML integrated into VS.

image

 

I took a look at the generated XML, which is the backing store for the diagrams, and it looks like it should work with source control much better than the usual modeling stuff in visual studio.

Another feature that is very welcome for anyone doing presentations is the use of CTRL+Scroll Wheel for zooming.

image

We are also promised performance improvements for large files, which is nice. Part of the walkthroughs talk about integrating functionality using MEF, which is good.

Looking at the walkthrough for creating syntax highlighting, tagging and intellisense, it looks like a lot of ceremony still, but it seems significantly easier than before.

WPF - It looks like VS is moving to WPF, although this CTP is still midway.

C# has dynamic variables!

dynamic doc = HtmlPage.Document.AsDynamic();

dynamic win = HtmlPage.Window.AsDynamic();

This was talked about in the MVP Summit, a dynamic object is an object that implements IDynamicObject:

image

Note that we accept an expression parameter (using Linq expressions) and we return a meta object. Show below.

image

This looks like C# + DLR integration, which is cool. I am looking forward to see what we can do with it.

VS also get some R# like features:

image

There is also a quick search, apparently, but I am not really impressed. Again, show me something that I don't have.

There is CLR 4.0, so we somehow skipped CLR 3.0. I am glad to know that we have a new runtime version, instead of just patching the 2.0 very slowly.

Threading

System.Threading.Tasks is new, and looks to be very interesting. It also seem to have integration with Visual Studio. It is also interesting because we seem to have a lot more control over that than we traditionally had in the ThreadPoll.

Parallel extensions are also in as part of the framework, not that this would be a big surprise to anyone.

In the CTP that I have, there is nothing about Oslo, models or DSL, which I found disappointing. I guess I'll have to wait a bit more to figure out what is going on.

That was a quick review, and I must admit that I haven't dug deep, but the most important IDE feature, from my perspective, is the CTRL+Scroll wheel zooming. The diagrams support is nice, but I am not sure that I like it in my IDE. Threading enhancements are going to be cool, and I am looking forward to seeing what kind of dynamic meta programming we can do with it.

Linq Update

time to read 1 min | 160 words

Yes, there is a new Linq CTP, but this isn't exciting. What is exciting is this post. The exciting thing about it is that I can now intermingle code & data freely. This is going to have some major reprecussions, I think. I can do it now, using LCG, but I don't know a lot of people that would like to do that on a day to day basis. This puts us in a whole different level.

One simple thing that this may mean is that I can build a smart cache that will take an expression tree, compile it to runnable code, check its in-memory objects using this code and if it is not found will use the expression tree to query a database. This is powerful.

The next bit of news that I would like to hear is a ship date, to tell you the truth.

time to read 3 min | 443 words

Right now, you can't pass delegates to attributes, which is a shame, this would open up a whole new world of powerful patterns. In C# 3.0, there are Lambda expressions, which make the idea even more attractive. Consider the following:

[Validation(string value => string.IsNullOrEmpty(value) )]

public string Name

{

    get { return _name; }

    set { _name = value; }

}

I'm certain that you can see the possibilities from here. This is declarative programming at its best, in my opinion. The nice part about this is that lambda expression can be serialized, and later they can be turned into code as well. This should turn out to be very powerful in many contextes.

I opened a ladybug here, please vote for it.

time to read 10 min | 1806 words

I've a confession to make. It's a very serious one. I don't like strings and Reflection. In fact, you could say that I hate them with a passion. I hate them because they hide important information from the compiler. This post is actually not a rant, it presents a solution to the problem.

I hate them so much that I wrote my own Mocking Framework that don't use strings at all. .Net has some really great stuff that you can do with Reflection, but it has two big problems.

  • It is a performance hit.
  • It uses strings.

I refactor a lot, and I just hate it when everything compiles okay, and then things breaks on runtime. I think that static reflection will enable writing amazing code. The functionality is already built into the CLR (check the ldtoken/ldftn IL instructions and friends). It didn't make it into the 2.0 release, but I hope that it will be in the next release. In the meantime, the 2.0 Reflection has been optimized, so that is what we have for now. But it's not enough for me. I discovered that you can do this:

Action<int> act = this.CalcSums;

So I figured out that I can create a library that would cheat the C# compiler (and I belive the VB.Net compiler as well) to give me a token for the method. Before I'll get into the details, here is a short sample of the code:

using System;
using System.Reflection;
public class StaticReflection
{
        #region void delegates
        public delegate void VoidFunc();
        public delegate void VoidFunc<A0>(A0 a0);
        #endregion
        #region delegates
        public delegate TRet Func<TRet>();
        public delegate TRet Func<TRet, A0>(A0 a0);
        #endregion
        #region void func Method Info
        public static MethodInfo VoidMethodInfo(VoidFunc func0)
        {
                return func0.Method;
        }
        public static MethodInfo VoidMethodInfo<A0>(VoidFunc<A0> func1)
        {
                return func1.Method;
        }
        #endregion
        #region func Method Info
        public static MethodInfo MethodInfo<TRet>(Func<TRet> func0)
        {
                return func0.Method;
        }
        public static MethodInfo MethodInfo<TRet, A0>(Func<TRet, A0> func1)
        {
                return func1.Method;
        }

        #endregion
}

The usage is simple:

public class Test
{
 public static void Main(string[]args)
 {
  MethodInfo thisMethod = StaticReflection.MethodInfo<int,int>(MultiplyByThree);
  Console.WriteLine(thisMethod);
 }
 
 public static int MultiplyByThree(int i)
 {
  return i * 3;
 }
}

The output of the above code is: "Int32 MultiplyByThree(Int32)"

Now, there is one huge advantage of this system, and it's the simple fact that it will fail to compile if you changed the name of the method and not the calling code. The other advantage it should have is in performance.

In order to test that I created two sets of tests. The tests are two classes, each with 10,000 methods, each class Main() needs to get a MethodInfo object for each of the methods. Here is a sample of the code:

Benchmarking the static reflection:

public static void Main(string [] args)
{
 DateTime start = DateTime.Now;
 MethodInfo method;
 method = StaticReflection.VoidMethodInfo(DemoClass0.DemoMethod0);
// ... 9998 more statements ... 
 method = StaticReflection.VoidMethodInfo(DemoClass9999.DemoMethod9999);
 Console.WriteLine("Took: {0}", DateTime.Now - start);
}

Benchmarking normal Reflection:

public class TestingUsingReflection
{
 public static MethodInfo GetMethod(Type type, string method)
 {
  return type.GetMethod(method);
 }
 
 public static void Main(string [] args)
 {
  DateTime start = DateTime.Now;
  MethodInfo method;
  method = GetMethod(typeof(DemoClass0),"DemoMethod0");
// ... 9998 more statements ... 

  method = GetMethod(typeof(DemoClass9999),"DemoMethod9999");
  Console.WriteLine("Took: {0}", DateTime.Now - start);
 } 

Here are the results.

Reflection .Net 2.0 & 1.1  218 - 187 Milliseconds
Static Delegates 125 Milliseconds

It's not a huge difference in the number, but it's something. And it's for 10,000 iterations. I was actually surpirsed that this happened. There doesn't seem to be any difference between 1.1 & 2.0 in this case (I imagine that it's not one that they optimized.) Using the static delegates took exactly 125 milliseconds each time I run it. It's not the performance that I'm looking at as the biggest advantage, it's the type safety in compile time.

Some things to note, there are two methods on the Static Reflection class, one for methods that has a return type, and one for those who don't. You can read the reason for that in Representing void methods with generic delegates.

The code (including the scripts I've used for generating the class and the benchmarks) are here. (You'll need Boo in order to run the benchmarks)

Enjoy,

time to read 8 min | 1568 words

Note: It's probably pretty early to start talking about patterns for C# 3, but the thought popped to my mind and wouldn't go away.

Mixin: In computer science, a mixin is a group of functions which can be mixed into a class and become methods. They allow certain classes to take on certain functionality, in an object-oriented programming including in languages that do not support multiple inheritance, just as if the class were a cooking dish and a mixin was a specific ingredient.

Ruby on Rails recently got a act_as_taggable mixin, which basically allows you to just slap a single line of code on a class and get tagging support. I'm going to show the C# 3 interface for a similar implementation. I don't care about the implementation, so we'll just assume that this is a given. I want to be able to tag any database object with as few lines of code as possible and just have it work like magic, the ideal is Ruby's single line of code. I'm going to show the ideal, the interface & client code and then talk about how this is possible.

Let's see what we would like to write:

//Createing taggable mixin
public mixin Taggable<T>
{
 public void TagWith(params string tags) { .. }

 public static T TaggedWith(params string tags, FindWith with) { .. }
}
public enum FindWith 
{
 AnyOfTheTags,
 AllTheTags
}
//Adding tagging to a class


public class Photo : Taggable
{
...
}

//client code:
// create photo and adding tags
Photo photo = ... ;
photo = Photo.TaggedWith("flower","sun","yellow""mayhem");
//Loading with tags

Photo photo = Photo.TaggedWith("flower", FindWith.AnyOfTheTags);

This is what we would like to have, but right now and in the future we are not likely to get it. We can get something very close. Here is what we would need to write:

//creating taggable mixin


namespace Tagging
{
 public static class Taggable
 {
  public static void TagWith(this ITaggable<T> tagged, params string tags) { .. }

  public static IList<T> TaggedWith<T>(params string tags, FindWith with) where T : ITaggable<T> { .. }

 public interface Mixin<T> 
  where T : ActiveRecordBase, Mixin<T>   { }
 }
 
 public enum FindWith 
 {
  AnyOfTheTags,
  AllTheTags
 } 
}
//Adding tagging to a class
public class Photo : ActiveRecordBase, Taggable.Mixin<Photo>
{
...
}
//client code

using Tagging;
//create photo and adding tags
Photo photo = ... ;
photo.TagWith("sun","rain","colors");
//load photo with tags
IList<Photo> photoWithFlowers = Taggable.TaggedWith<Photo>("chaos",  FindWith.AnyOfTheTags);

So, what do we have here? We have a static class with extention methods that refer to the Taggable.Mixin<T> interface. The Taggable.Mixin<T> interface require that implementing class will inherit from ActiveRecordBase and implement ITaggable*, this is so the Taggable class will have a way to work with the database, (that is an implementation detail, it can certainly be done in other ways).

Then we have the Taggable class, which has an extention method to add tags to an object, and a static method (not an extention one), which takes a Taggable.Mixin type and return a list of the tagged instances of it. Check out the bolded lines, those is what you've to do in order to get the taggable support for an object. Add a declaration to Taggable.Mixin, and your object is set. Then in the client code just import the Tagging namespace, and you can use it as if it was part of the object.

I think that this is a really nice way to add functionality to objects in a non intrusive way. The client code can actually choose whatever it wants to be exposed to the tagging support or not, and all the class have to do is to declare its intention to accept the mixin.

As I said, it's a pretty pre-mature to start thinking about patterns for C# 3 (C# 2 is not yet released, after all), but I'm willing to bet quite a sum that this will be the way to create mixins is the .Net framework. This is just one of the cool things that you can do with the things that C# 3 will gives you. I expect a lot more goodies along the ways. The new features are useful for so much more beyond Linq.

One thing to considered, it's pretty early to say anything, but I can certainly see libraries such as the Boost providing tremendous value for developers in the C# 3 world.

* Implementing Taggable.Mixin - since Taggable.Mixin is an empty interface, the constraints here are just a way to say that any Taggable.Mixin must inherit from ActiveRecordBase. It's a nice way to declare things, since now we can say: ITaggable<Photo> is ActiveRecordBase, and it's always true.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. re (22):
    19 Aug 2019 - The Order of the JSON, AKA–irresponsible assumptions and blind spots
  2. Design exercise (6):
    01 Aug 2019 - Complex data aggregation with RavenDB
  3. Reviewing mimalloc (2):
    22 Jul 2019 - Part II
  4. Production postmortem (26):
    07 Jun 2019 - Printer out of paper and the RavenDB hang
  5. Reviewing Sled (3):
    23 Apr 2019 - Part III
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats