NET Progress

A Practical Step in the Stored Proc Debate

noreply@blogger.com (John Rusk) — Tue, 26 Aug 2008 08:14:00 +0000

I've taken a practical step in the long-running debate for and against stored procs.

I've logged a formal suggestion with Microsoft asking them to correct their erroneous advice on the subject. :-)

This Patterns and Practices page says:

Stored procedures generally result in improved performance because the database can optimize the data access plan used by the procedure and cache it for subsequent reuse.

That's been factually incorrect for the last decade! In terms of query plan caching, Parameterized SQL and Stored Procs are handled in the same way - and they have been since SQL Server 7.

So, if you too are disappointed by the level of erroneous information in this long running debate, head over to the feedback page and support my request to fix the P&P page. You can support it via commenting on the page or by using the Validation link at the top.

Let's hope we can get the page corrected, and achieve a small step for rationality in an often irrational debate :-)

(Apologies to Microsoft if my tone sounds hash. I know you've already got the right information up on other parts of your site. Here's hoping to see P&P updated too.)

Software Development Meme

noreply@blogger.com (John Rusk) — Fri, 18 Jul 2008 09:11:00 +0000

I've been tagged by Andrew, in a software development meme that started way back here.

How old were you when you started programming?

I was exactly 13. My parents bought me my first computer for my 13th birthday. It was a second-hand Ohio Scientific Superboard II.

By the way, the Superboard shipped in 1978 as a single circuit board. It had keys mounted on the front and chips mounted on the back. That’s it. No case, no nothing – just one big circuit board with stuff on it. By the time it reached me a few years later, mine had been fitted into a hand-built wooden case, and its memory had been expanded to 16k. (I still have the machine. If anyone knows how to fix a Superboard II that won’t respond to the Break key after power-up, please contact me :-)

How did you get started in programming?

Before my SuperBoard, I’d only seen two other computers. I guess they must have made a big impression on me. I got Mum and Dad to buy me a book on programming in BASIC, and the purchase of the actual computer followed sometime after. I don’t recall how much nagging was involved ;-)

What was your first language?

The Superboard’s version of BASIC, which was apparently "Microsoft 6502 BASIC version 1.0 revision 3.2". In hindsight, I love the fact that it was simple enough for a 13 year-old to learn the whole language. If I recall correctly, there was IF .. THEN, but no ELSE; and GOTO but no GOSUB. Definitely a minimal language. It made me appreciate "real" languages when I finally got to use them.

What was the first real program you wrote?

It was a clone of the first computer program I’d ever seen – a game where you had to steer a tank through a minefield. My version had the randomly-generated minefield, and the tank that was stuck on full-throttle while you steered your way though, but it lacked the system-generated comments that poked fun at your crashes.

What languages have you used since you started programming?

I’ve done serious development in Pascal, Excel 4.0 Macro language, VBA, Ada, PowerBuilder, PL-SQL, Delphi and C#. I’ve dabbled in various others including C++, JavaScript and even VB.NET (although it makes my eyes hurt when I read it ;-)

What was your first professional programming gig?

I did a few small jobs in BASIC and Excel when I was a student, but my first really serious job was in PowerBuilder for an IT consultancy. PowerBuilder’s (in)famous DataWindow really was a fast way to get things done. It set the bar for productivity, and it's only now in 2008 that I feel like we've replicated that speed in .NET - thanks to a good ORM and our in-house framework. (And we get a proper domain model with layering, which we never had in PB!)

If you knew then what you know now, would you have started programming?

Yes.

If there is one thing you learned along the way that you would tell new developers, what would it be?

I might tell them that it’s not about technology, it’s really about people – but I don’t think they’d believe me.

So instead I’d tell them to read How to be a Programmer.

What’s the most fun you’ve ever had... programming?

I’ve particularly enjoyed my old Superboard; writing (most of) a compiler at university; doing some funky stuff with COM in Delphi; and releasing a couple of open source projects.

But the thing I look back on most fondly is a .NET project at Optimation. The highlight wasn’t the technology, which was interesting but not amazing; the highlight was the project as a whole. We had great collaboration with the customer, very much "one team" with great dialogue and innovation, and together we exceeded expectations instead of merely meeting requirements.

Over to you

Bevan
Eduard
and
Kirill

POCO LINQ Update

noreply@blogger.com (John Rusk) — Tue, 15 Jul 2008 10:08:00 +0000

Here is my long-promised near-POCO solution for LINQ to SQL.

As planned, it is deliberately not 100% pure POCO, but it does implement these key goals:

Entity classes are simple enough to be hand-written (no need to generate them with SQL Metal or VS 2008)

Mapping is easy (no need to manually map every property via attributes or external XML)

Lazy-loading works

Bi-directional relationships work (update one end, and the other is synchronized automatically)

Another reason why architects should write code

noreply@blogger.com (John Rusk) — Sat, 07 Jun 2008 21:20:00 +0000

Johanna Rothman explains why architects should write code. I completely agree.

Not only does hands-on involvement reduce risks on the project, it also reduces embarassment when talking to your kids ;-) Here's an actual conversation with my daughter:

What did you do today Dad?
I drew some diagrams. Do you know what a diagram is?
No
It's a picture that shows how something works. I drew some diagrams, then I talked with some people about them.
So you didn't do any work then?

Only 4 New Features in C# vNext?

noreply@blogger.com (John Rusk) — Wed, 30 Apr 2008 08:51:00 +0000

I've always admired the effort that Microsoft put into the design of C#. It's difficult to find the right balance between power and flexibility, and on the whole I think they've done an excellent job.

At the same time, it's been great to see the language grow, particularly with the addition of LINQ. As Jon Skeet has written recently, C# today is noticably more complicated than it was at version 1.0. Personally, I don't think that's a bad thing. The C# community has grown up along with the langauage, learning the new features as they have been released.

I can see this process continuing for some time, with the language continuing to grow. So I was suprised to see this comment from Microsoft's Mads Torgersen, in response to some suggestions that I posted at Microsoft Connect:

"We have to do some harsh prioritization, both because of our implementation and testing resources, but also because we need to keep the number of new langauge features at a manageable level - depending on how you count, we are adding only four language features to C# this time around".

We more-or-less know that one will be some form of dynamic lookup. That just leaves three others. They might be big "killer" features (like generics and lambda expressions in previous versions) but there's still only three of them.

I don't know what to think. Should we be trilled that Microsoft are continuing their excellent track record of keeping the language simple, or should we be dissapointed that there will be so few improvements?

Summary of C# vNext Ideas in this Blog

noreply@blogger.com (John Rusk) — Sun, 24 Feb 2008 05:30:00 +0000

Here's a summary of the ideas I've suggested in this blog, for future versions of C#:

Fix the versioning issues with extension methods
Consider "extension interfaces" to provide mixin-like behaviour
Also, consider improving the resolving of extension methods
Retain some means of serializing iterator state (even if the underlying iterator implementation is changed) (See comments here)
Provide an infoof operator, or similar
Better handling of @-quoted strings that contain double quotes
Enhance automatic properties to retain their concise syntax but to offer greater flexibility to use programmer-defined code. Particularly helpful for automatic INotifyPropertyChanged implementation

Enhanced Automatic Properties

noreply@blogger.com (John Rusk) — Sun, 24 Feb 2008 04:41:00 +0000

Recently there's been a lot of blog posts discussing things people would like to see in the next version of C#. Here's my addition to the wish-list:

"Automatic properties that let me supply a method body." It sounds like a contradiction in terms - but it doesn't have to be. Instead, it would be a compact syntax for defining properties that use standardised method bodies (where you define your own "standard" bodies).

Some places where it would be useful:

Cases where many properties follow a standard format. For instance, all the properties generated by the LINQ designer could be single-line automatic properties. (Much less verbose than the current approach).
ORM's and similar products that require properties to be written according to certain conventions. (E.g. Mindscape LightSpeed)

How would it look?

Right now, we can write automatic properties like this:


public int Foo { get; set; }

My suggestion is that the words "get" and "set" could be replaced by the names of methods. For instance:


public int AdvancedFoo { GetValue; SetValue; }

Where the methods "GetValue" and "SetValue" are generic instance methods with these signatures:


/// <summary>
/// When passed the field, return the property value
/// </summary>
T GetValue<T>(ref T field)
{
    // ... your own code goes here...
}
       
/// <summary>
/// When passed the field, by ref, and the new property value, set the field
// </summary>
void SetValue<T>(ref T field, T value)
{
    //...your own code goes here...
}

Given the above property, "AdvancedFoo", the compiler would compile it as if I had written this:


public int AdvancedFoo
{
    get { return GetValue(ref _advancedFoo); }
    set { SetValue( ref _advancedFoo, value); }
}

private int _advancedFoo; // compiler-generated backing field

Just as in today's automatic properties, the compiler would generate the backing field for me. The difference is that it reads and writes that backing field via methods which I define.

This goes a long way towards giving the best of both worlds: the compact syntax of automatic properties, and the flexibility of my own code (plus standardisation - all me properties that are supposed to work the same way do work the same way, because they all use the same code).

Questions:

Why does the "GetValue" method take the field "by ref"? SetValue needs it by ref, but why GetValue? GetValue takes it by ref simply so that you can use this trick to find out which property is being read - just in case you need to know. This is something you are more likely to need to know when setting, e.g. to raise change notificiations, but maybe some people want to identify the property in GetValue too. Using the ref param makes that possible.

What type should the complier use for the backing field? Simply put, it should use whatever field type is implied by the field parameters of the "GetValue" and "SetValue" methods. E.g. an automatic property for a LINQ EntityRef might look like this:


T GetEntity(ref EntityRef<T> field) where T:class
{}

void SetEntity(ref EntityRef<T> field, T value) where T:class
{}

allowing me to write this:


public Customer Bar{ GetEntity; SetEntity; }

and have the compiler compile it as if I had written this:


public Customer Bar
{
    get { return GetEntity(ref _bar);}
    set { SetEntity(ref _bar, value);}
}
private EntitySet<Customer> _bar;

Note that the compiler is able to infer that the backing field should be EntitySet, not Customer, based on the signatures of Get/SetEntity.

(And how would Get/SetEntity actually work? That's a question for another day ;-) I do have some (working) prototype code...)

What do you think of this idea for enhanced automatic properties?

Update 2 March: posted on MS Connect here (in the comments)

Update 12 March: And here here as an MS Connect item in its own right.

Extension Methods - Feedback to Microsoft

noreply@blogger.com (John Rusk) — Thu, 14 Feb 2008 08:43:00 +0000

If you've been following the disussions about extension methods in this blog, you might be interested to know that I've submitted the issue to Microsoft's feedback site. Jump over there and vote for it, if you'd like to see something done.

Better Property Change Notification

noreply@blogger.com (John Rusk) — Fri, 08 Feb 2008 22:58:00 +0000

aka Automatic INotifyPropertyChanged

Some time ago I developed a new way to do property change notification. It consists of code which can automatically figure out which property has changed, without you having to tell it.

Details are here.

I've now put together an updated version, and posted it on CodePlex here.

Here's how to use the new version:

Option 1:

Here's the easiest option...

Add this code to your class or base class:


PropertyChangeHelper _propertyChangeHelper = new PropertyChangeHelper();

public event PropertyChangedEventHandler PropertyChanged
{
    add { _propertyChangeHelper.Add(value); }
    remove { _propertyChangeHelper.Remove(value); }
}
            
protected void SetValue<T>(ref T field, T value)
{
    _propertyChangeHelper.SetValue
                          (this, ref field, value);
}

Then write your property setter methods like this:


public int Foo
{
    get { return _foo; }
    set { SetValue(ref _foo, value); }
}

Option 2:

If you want more control, you can find which property changed like this (and then do whatever you like):


protected void SetValue<T>(ref T field, T value)
{
    ...
    field = value;   //Actually assign the new value
    PropertyInfo changedProperty = PropertyMap.GetProperty(this, ref field);
     // do whatever you like, now that you know which prop was changed
    ...
}

Key differences in the new version are:

No "trial sets". The old version used to call all your property setters, to figure out which fields they corresponded to. That could be annoying, because you ended up recieving calls to the set methods when your objects were not necessarily ready for them. The new version doesn't need to do this. Instead, it inspects the MSIL of the set methods, to figure out what it needs to know. (The inspection is a one-off runtime operation, so it won't be a performance problem.)

Fewer contraints on how classes are coded. The old version required that you nominated a special field as the "reference field", to which all others were compared. The new version does not require that. Also, the new version lets you use your own base class (with your own SetValue method, named whatever you want). Fianlly, you can put your own code in the property setter methods (along with the call to your "SetValue" method), something which could cause problems in the old version

Helper class for easy implemetation of property change notifications (as above)

Granualar implementation, so that you can call some of the implmentaiton classes, but still write the outer "layer" of the API yourself if you need to

Lock-free. The new version is threadsafe without explict locks (and without and [ThreadStatic]s). Update 10 Feb: This used to rely on a little trick with generics and static fields; but that doesn't play well with inheriance. It now uses a class I wrote called LazyDictionary, which is basically a dictionary with double-checked locking to ensure that locks are only requested during initialization, and not during the on-going running of the application. (Didn't want a lock request on every property set call!)

No separate C++ assembly. The old version used managed C++ to do stuff that C# cannot. The new version uses reflection emit, to produce the corresponding routine on the fly, so that the separate assembly is not required.

Finally, I have resurrected the name "ActiveSharp" (which I used for a previous, abandonned project) for this new version of the code. I did that for two reasons, firstly the new version borrows code from the old ActiveSharp (particulaly the MSIL inspection); and secondly I liked the old name and couldn't think of a better one ;-) Just like the previous "ActiveSharp", this new version is a product of my microISV, Tasman Logic Ltd. (The microISV is not exactly a money-making venture, given that its only product is open-source ;-)

Resolving Extension Methods

noreply@blogger.com (John Rusk) — Tue, 15 Jan 2008 07:11:00 +0000

Paul Stovell (author of SyncLINQ) has pointed out another issue with Extension Methods. As he writes:

The problem is the methods are *resolved* at compile time.

Suppose you had this:

void DoStuff(this IFoo foo);

class FooFactory
IFoo Create()

If your factory returns an object that provides its own instance implementation of DoStuff, it WILL NOT be invoked - the extension method will instead. This breaks many of the rules around polymorphism and good OO in general...

In other words, the compiler favours instance methods over extension methods, but only if it can "see" the instance method at compile time.

The reason is simple: currently, resolving an extension method is just a compiler trick, so compile time is the only time when it CAN be done.

But Paul's comment got me thinking. It occured to me that, if my idea about using interfaces was implemented, then it would be possible to properly solve the problem he described. It would work like this:

First, to recap: I suggest that there should be a mapping between extension methods and interfaces. Think of a set of extension methods as an "extension contract". You can make calls on the methods in that contact either by calling intstance methods (on objects which implement the interface) or by extension methods (for objects which do not implement the interface). This is to solve the versioning problem, but it can also be used to solve the problem Paul described.

How? I'll try to illustrate with an example. Imagine that our "extension contract" is called IExtensionContract. It contains two methods, Foo and Bar. We can call Foo and Bar on objects which don't support IExtensionContract, simply by calling them as extesion methods. But, when we call Foo and Bar on objects which DO support IExtensionContract, we want to call the version that is on the object even if we can't tell that the object supports them at compile time. (That's the heart of the issue, right Paul?)

That could be done if the complier worked like this:

Given this code to compile

ISomething s = ...
s.Foo();

The compiler should compile it as if the programmer had written


ISomething = ...
IExtensionContract c = s as IExtensionContract;
if(c == null)
   StaticExtender.Foo(s);  // invoke the extension method
else
   c.Foo();                // invoke the instance method

This would be possible, if the interface-based versioning solution was adopted, because that solution introduces just enough runtime information about the extension methods - namely the "contract" to which the methods belong. Contrast that to the current situation, where there is no runtime information about extension methods.

Here is the user-authored (i.e. not compiler-generated) code for the example above:


public static class StaticExtender : IExtensionContract 
    // "inheriting" from interface here is my suggested addition to the language
{
     public static Foo(this ISomething s){...}

     public static Bar(this ISomething s){...}
}

public interface IExtensionContract
{
   void Foo();
   void Bar();
}

Finally, all the suggested logic I have blogged about previously still applies. The compiler still needs to decide, at compile time, whether the call is to a method in the extension contract or to a like-named (but otherwise unrelated) instance method. All that logic still applies as I described it here.

Readability in Validation

noreply@blogger.com (John Rusk) — Sun, 13 Jan 2008 00:59:00 +0000

My favourite pattern for validation code is to have one method per validation rule. I think it makes it easier to read and manage the rules.

For instance, I like to be able to write something like this:


[Validate]
protected bool EndDateMustBeAfterStartDate()
{
  return EndDate > StartDate;
}

I like to refine the pattern a little, in order to:

(a) Construct error messages based on the method names. That makes the code more concise and encourages good method names. E.g. the failure message from the rule above will be "End date must be after start date".
(b) Allow you to, alternatively, specify dynamically-generated failure messges from within the method body (see below)
(c) Easily specify if the rule is not applicable in a particular situation (again see below).

I've attached some sample code (with tests).

By the way, I once wrote some code to fire rules automatically, whenever a property used by the rule was changed. But that's not included here. In this sample, you have to ask the system explictly to run the rules at a particular time.

Here are some example rules, and the code to call them:


public class Animal
{
    ...
    public string AnimalName
    {
        get { return _animalName; }
        set { _animalName = value; }
    }

    public int NumberOfLegs
    {
       get { return _numberOfLegs; }
       set { _numberOfLegs = value; }
    }

    [Validate]
    protected Result NumberOfLegsMustBeEven()  
    {
        return NumberOfLegs % 2 == 0;
    }

    [Validate]
    protected Result MythicalSpeciesAreNotAllowed()
    {
        if (AnimalName == "Unicorn" || AnimalName == "Dragon")
            return Validation.Error("'" + AnimalName + "' is not a real species");
        else
            return Validation.NotApplicable;
    }  

    // Note the use of the OR operator here to give a compact syntax for returning a custom error
    [Validate]
    protected Result NumberOfLegsMustBePlausible()
    {
        return NumberOfLegs <= 10 || Validation.Error("Your '" + AnimalName +  "' has too many legs");
    } 

...
// execute like this
   foreach(Result r in Validator<Animal>.ExecuteRulesOn(myAnimal))
     if(!r.Pass)

// or, like this, if you don't want to use the generic Validator class
Validator v = Validator.GetInstanceFor(typeof(Animal));
foreach (Result r in v.ExecuteRulesOn(myAnimal))
  ...

Interested in POCO LINQ?

noreply@blogger.com (John Rusk) — Sat, 29 Dec 2007 08:43:00 +0000

I've been investigating using LINQ to SQL with a POCO approach. (POCO = Plain Old CLR Objects.) My ideal solution would be something like this:

Entity classes are simple enough to be hand-written (no need to generate them with SQL Metal or VS 2008)

Mapping is easy (no need to manually map every property via attributes or external XML)

Lazy-loading works

Bi-directional relationships work (update one end, and the other is synchronized automatically)

The last two points are the most problematical. In LINQ to SQL lazy loading requires the use of EntitySet and EntityRef. However, it's not easy to use those classes in hand-written code. In fact, it is generally recommended to dispense with these classes if you want to "go POCO". But that deprives you of lazy loading. You also lose out on Linq’s support for bi-directional relationships, because it is also based on EntitySet and EntityRef.

I want a solution that supports all four goals outlined above. [Update: here it is]

Question: If I can find one, would you be interested in it?

If enough people say yes (either in comments below or via email), I’ll try to post something within the next few weeks.

I understand that knowledgable people have said this can't be done. I respectfully disagree ;-) Based on work so far, I’m satisfied that it can be done.

Update: The idea would be that you'd hand-write .NET classes, according to a few simple conventions. Do that and you'd automatically get working bidirectional relationships and lazy loading, plus automatic runtime generation of the correct mappings. (You'd never use SQL Metal or the Visual LINQ designer.)

You could also generate the database if you want. (I.e. the usual model is generate-code-from-database; this would allow (but not require) generate-database-from-code). If you use TDD, you could create and test the objects using TDD (running in-memory tests) and then generate the database.

Other simple little benefits would be: e.g. could have one file per class (which you can't with MS's generators); could put comments on the properties of those classes (which you can't with MS's generators, as far as I can tell), could put your own attributes on the entity/domain object classes, e.g. for attribute-based validation frameworks (again, you can't with MS's generators), entity classes compact enough to actually read them ;-)

Footnote: In this post I’m talking specifically about LINQ to SQL. I know that there are (or soon will be) several fine independent ORMs that use the LINQ language features to create their queries, but execute those queries with their own backend. A number of these products support POCOs but, for my current project, I need a solution for the full Microsoft "stack" - including LINQ to SQL.

Update on Persistent Iterators

noreply@blogger.com (John Rusk) — Fri, 21 Dec 2007 07:19:00 +0000

Some time ago I wrote about implementing workflow with persistent iterators. This is just a reminder (in case you missed it in the comments on the original post) that Microsoft are going to change the implementation details. Until they announce details of the change, we can't be sure whether the technique I posted will work in future versions of C#.

Mads Torgersen, the C# Language PM, wrote:

We are likely to in fact change the way iterators are implemented in future versions. That said, we might be able to implement a serialization format that would work across such future changes. I agree with you that this would be a very useful feature.

If you want to use this technique in future versions, head over to this page and vote for it.

Making Extension Methods Safer

noreply@blogger.com (John Rusk) — Sat, 17 Nov 2007 07:59:00 +0000

(Note: This post refers to my previous posts about extension methods. It won't make much sense unless you read those posts first).

Last year I blogged about extension methods, explaining a risk and suggesting a solution. Now that Visual Studio 2008 is (almost) released, without any solution to the problem, I'm wondering if a solution could be added in a future release.

Yes, it could.

It would be as simple as this:

Get the compiler to raise warnings when an instance method takes precedence over an extension method. (This would apply to all extension methods, whether they are in extension interfaces or not).
Allow the warning to be dealt with in these ways. Either:

(a) Suppress the warning using #pragma warning or the IDE's list of warnings to supress. If you do this, you get the existing Visual Studio 2008 behaviour. OR
(b) Make the intent of the code explict at the call site. If you want the extension method, call it explicitly as a static method; if you want the instance method, call it explicitly with a syntax such as the hypothetical one I proposed here. OR
(c) Let the complier supress the warning for you automatically. To do so, put all the extension methods into an extension interface and make the instance implement the same interface. Then, the compiler can safely choose the instance method without issuing a warning.

For instance, in Visual Studio 2010 (or whenever it may be), Microsoft could safely put all the LINQ extension methods into extension interfaces. Users who don't care about this stuff could simply ignore or suppress the warning (option a), ending up with exactly the same behaviour they have now.

Users who do care could choose option (c), simply by implementing Microsoft's new interfaces on their own classes. That's easy, because the users already have the methods that are in the interface (that's why they are getting the warning!) so all they need to do is add the interface name to their class's list of ancestors.

The user is then left with warnings for only those rare cases of genuine ambiguity, cases where the semantics/purpose of the instance method differs from that of the extension. That's exactly when a warning is needed. These rare cases would be addressed with option (b).

In conclusion, Microsoft could safely fix the extension method problem in future version of Visual Studio.

(Update: another reason to adopt this solution)

SmartRegex

noreply@blogger.com (John Rusk) — Fri, 02 Nov 2007 09:25:00 +0000

Jeff Attwood blogged about his dislike of fluent interfaces. He happened to use Joshua Flanagan's fluent regex API as his example.

When Joshua first posted his example, last year, it inspired me write a more compact alternative. While the fluent style began in the Java community, the compact alternative uses the unique features of C# to deliver an easy-to-read result - without the verbosity of the fluent style.

Thanks to a little encouragement from Joshua, today I am posting the source code. I've called it "SmartRegex". Here's the source code, and here are the unit tests. The last of the tests is a full test of the exact example used by Joshua and Jeff.

Note that this version of SmartRegex contains just enough to implement Joshua's example. It does not support the rest of the regex syntax. If you are interested in a more complete example, email me or leave a comment below and I'll see what I can do.

Query Errors and Identity Map

noreply@blogger.com (John Rusk) — Sun, 02 Sep 2007 05:45:00 +0000

I’ve encountered a “gotcha” in O/R Mapping. I’ll describe it here, and outline some of the possible solutions. To make matters worse, the default solution in nHibernate has side effects which can cause problems of their own. I’ll cover those side effects too.

The Problem

Imagine doing this in one Unit of Work (aka Session in Hibernate-speak):

1. Load customer “Bob Smith”
2. Change his surname to “Jones” (but don’t save yet)
3. Now, ask the ORM to load all customers named “Smith”.

Depending on how your ORM works, the list of Smiths may include one guy named Jones!

Why? Because he is still “Bob Smith” in the database. The ORM grabs the database row for Bob Smith, sees that the corresponding object has been loaded already (via the Identity Map pattern), and so returns the already-loaded object – even though that object is now named Jones.

There are several possible solutions to this problem, as follows:

1. Automatic “eager updates”. This is the default solution used in Hibernate and nHibernate. When FlushMode is set to its default value (Auto), nHibernate will send updates to the database early (i.e. before you ask it to) just to make sure that your in-memory changes also exist in the database, and therefore are reflected in the results of your queries. In the example above, nHiberate would automatically save Jones before querying for the list of Smith’s. This solution guarantees accurate results, but it has a problem (which I’ll describe below).

2. Cross check database results with in-memory state. This solution would involve scanning all objects already in the identity map, in addition to running each database query. Due to the obvious performance implications, particularly if there are a lot of objects in the identity map, I won’t discuss this option further. [See comments below for discussion of performance implications]

3. “Don’t worry about it”. Simply don’t solve the problem at all. Go ahead and return Jones in the list of Smiths. Rely on the application programmer to know when this might be dangerous. In cases where the programmer thinks this will cause a problem, the programmer can either:

3.a. Explicitly save changed objects before running the problematic query – this is a manual version of option 1 above, but it only kicks in when the programmer thinks they need it. I believe this is the approach taken by LINQ-to-SQL.(*)
3.b. Explicitly run two queries: the first runs against the database and loads the objects into the unit of work (aka session). The second runs in memory, scanning over all the objects in the unit of work, returning those that match. Only results from the memory query are actually used. In our example above, Jones would be processed by the first (database) query, but not by the second (memory) one. I’m not aware of any ORM that implements this approach(**)

4. Solve the worst half of the problem... There are actually several types of error that may occur. Arguably, the worst type of error is the one I showed above. Say you query for all "Smith"s, and the proceed to perform some operation on each object returned, an operation which is only valid for people named Smith. It's not valid for people named Jones, so you may execute it in error when the ORM returns a Jones mixed in with the Smiths. This problem can be solved by a variant of option 2: query the database, let the identity map do its thing, and then execute the criteria again in memory on the final result set. Strip out all objects that fail the in-memory test. This option performs better than 2 because it doesn't scan all objects in memory, just those that were returned by the database query and were already in the identity map. (i.e. just Jones, in the example above). This approach guarantees to exclude all bad data, but it does not guarantee to include all good data. (E.g. it won't include new Smiths which have not yet been saved.) I implemented this option in ActiveSharp. [See comments below for discussion of why this is worth doing and why, unlike option 2, it can be implemented efficiently]

The Problem with the nHibernate Approach

Let’s introduce the problem with a quote from the nHibernate documentation:

Many business processes require a whole series of interactions with the user interleaved with database accesses…[This is called] a long running application transaction. A single application transaction usually spans several database transactions. It will be atomic if only one of these database transactions (the last one) stores the updated data, all others simply read data.

But, when automatic flushing is enabled, any transaction may update data! Even if you roll back the last one (the one which is supposed to do all the updates) Hibernate may have already committed some “eager" updates in earlier transactions. Therefore, automatic flushing is incompatible with long application transactions.

In summary, you have two choices in nHibernate:

(a) Automatic flushes, usually in the session-per-request pattern.
Pro: accurate query results;
Con: must use one database transaction for entire session (to prevent unwanted commits of automatic flushes)

(b) Manual flushes, usually in the session-per-conversation pattern (aka session-per-application-transaction).
Pro: can use multiple database transactions per session, flushing only in the last one;
Con: query accuracy may suffer as described above.

I am disappointed to see nHiberate documentation which says that “the ISession.Find(..) methods will never return stale data; nor will they return the wrong data”, without specifically spelling out that this is only true with automatic flushes. Likewise I am disappointed to see the session-per-conversation pattern described, with a perfectly valid recommendation to turn off automatic flushes, but with no mention of the adverse effect on query accuracy.

[Update 26 Aug 08: Looks like nHibernate 2 has tightened things up somewhat, since it has "No AutoFlush outside a transaction - Database transactions are never optional, all communication with a database has to occur inside a transaction, no matter if you read or write data." So at least if it is going to send your updates to the database, it will be in a transaction that you have created yourself. Still no guarantee (as far as I can tell) that the transaction used for the updates will be the "last" one - i.e. the one where you intend all updates to happen]

Conclusion

With manual flushing, accuracy of query results is a potential problem. Admittedly, it will be a rare problem in practice, but sometimes the rare problems are the most dangerous -- because they’re the hardest to find in testing.

I can’t find much about the problem on Google. Perhaps I’m not searching well enough… or perhaps the information is out there but I can’t find it because Martin Fowler hasn’t given it a catchy name yet ;-) …

Certainly, I agree with the usual recommendation to make sessions as short as practically possible. That may minimize the problem – but it won’t 100% eliminate it, particularly for application transactions that span multiple database transactions.

I think it’s important to understand when an ORM may give “incorrect” results. It’s also important to understand the side effects of Hibernate’s eager-update solution.

Finally, I’m relatively new to nHibernate. If I’ve missed something important, please let me know.

References:
Hibernate transaction patterns:
http://www.hibernate.org/hib_docs/reference/en/html/transactions.html

Stale data in LINQ-to-SQL:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2078814&SiteID=1&mode=1
(at the time of writing this post, my own question in the thread has not been answered)

Another post on LINQ issues, which mentions the stale data issue:
http://damieng.com/blog/2007/05/16/linq-to-sql-details-issues-and-patterns

Uniquing (aka Identity Map):
http://www.ayende.com/Blog/archive/2006/09/03/7294.aspx

(*)The programmer will generally need to make sure that the explict "early" save is in the same database transaction as the rest of the intended updates. This is for the same reasons outlined above with regard to automatically-flushed updates in Hibernate.

(**)This option is achievable, because with LINQ, it is relatively easy to run the same query once against the database and once against the objects in memory. But, it is basically just a manual version of option 2 above, but it only kicks in when the programmer thinks they need it.
Importantly, to be truly accurate, options 2 and 3b must include new objects that have been added to the unit of work but not yet saved to the database. This is not possible in most (all?) true POCO ORMs, since their persistence-by-reachability code only kicks in when objects are saved. That’s too late for options 2 and 3b, which require the ORM to know about objects as soon as they become reachable from any other object in the Unit of Work, even if they have not been saved yet.

Workarounds to Simulate Static Imports

noreply@blogger.com (John Rusk) — Sun, 19 Aug 2007 02:48:00 +0000

Sometimes, it would be handy to write methods without preceeding them with an object or type. E.g. it would be nice to write

Sin(x) / Cos(x)

instead of

Math.Sin(x) / Math.Cos(x)

The shorter version is not possible in C#, so this post outlines all the workarounds I know of.

Introduction

In Java, and some other languages, you can omit "Math." by doing a "static import" of the "Math" class. I asked Eric Gunnerson (ex C# Progamme Manager at MS) why static imports are not allowed in C#. He responded here, and I paraphrased his response as follows:

"Regardless of whether you see

> ...Color.Red
or
>...System.Drawing.Color.Red

you always know that Red is something defined outside of the class you're current reading.

Compare that to

>Math.Sin(x)
versus
>Sin(x)

In the latter you have lost the clear hint that Sin is "outside the current class". It could be a method on the class you're reading, or it might not. So static class imports create a bit more ambiguity than namespace imports, which I think was Eric's point."

Nevertheless, something like static imports can be useful for DSL-like solutions. Anders Noras gives a good example (and an interesting discussion) here.

His sample Java code looks like this:


Dim doc As XmlDocument
doc = Document( _
   Element("Employees", _
       Element("Employee"), _
           Comment("Highly valued employee..."), _
           Element("Id", 42), _
           Element("Name", "Arthur Dent"), _
           Element("ContactInfo", _
               Element("PhoneNumber", "555-5555"), _
               Element("Address", "Upda road 42"), _
               Element("Country", "England"))))

Here are all the ways I know of to simulate that kind of API in C#:

1. Simple ugly static methods


XmlDocument doc = DocHelper.Document(
   DocHelper.Element("Employees",
       DocHelper.Element("Employee"), _
           DocHelper.Comment("Highly valued employee..."),
           DocHelper.Element("Id", 42),
           DocHelper.Element("Name", "Arthur Dent"),
           DocHelper.Element("ContactInfo",
               DocHelper.Element("PhoneNumber", "555-5555"),
               DocHelper.Element("Address", "Upda road 42"),
               DocHelper.Element("Country", "England"))));

Ugly.

2. Make the thing before the dot look nicer.

2a. Creative naming of static classes
Sometimes you can do this with creative naming of static classes. For instance, instead of writing "CommonFunctions.EnsureNotMissing(...)" name the static class "Ensure" and write "Ensure.NotMissing(...)".

2b. Use instance methods, so you just have a single letter before the dot:


DocHelper a = new DocHelper();
XmlDocument doc = a.Document(
   a.Element("Employees",
       a.Element("Employee"), _
           a.Comment("Highly valued employee..."),
           a.Element("Id", 42),
           a.Element("Name", "Arthur Dent"),
           a.Element("ContactInfo",
               a.Element("PhoneNumber", "555-5555"),
               a.Element("Address", "Upda road 42"),
               a.Element("Country", "England"))));

3. Use constructors instead.

In this option, you write "new Element(...)" instead of "a.Element(...)"

4. Chain methods together "fluent" style

The downside of this is that you have to change your methods to return objects that support the next methods that you may call. While clever, this adds a level of complexity and so should be used with care. In general, I think there are better options.


XmlDocument doc = DocHelper.Document()
   .Element("Employees",
       .Element("Employee"), _
           .Comment("Highly valued employee..."),
           .Element("Id", 42),
           .Element("Name", "Arthur Dent"),
           .Element("ContactInfo",
               .Element("PhoneNumber", "555-5555"),
               .Element("Address", "Upda road 42"),
               .Element("Country", "England")));

5. Define methods in a base class.

This gives the desired syntax, but limits usage to derived classes. Depending on your particular needs, this may be a show-stopper.

6. Define methods in a base class, call from special one-off subclasses

Consider Anders' example. We are trying to create an XML document. As long as we are willing to define a class that corresponds to that particular document instance, we can write this:


void SomeMethod()
{
   XmlDocument doc = new OurCoolDocument();
   //...
}

private class OurCoolDocument: DocumentWithHelperMethods
{
   public OurCoolDocument():base(
       Element("Employees",
           Element("Employee"), _
               Comment("Highly valued employee..."),
               Element("Id", 42),
               Element("Name", "Arthur Dent"),
               Element("ContactInfo",
                   Element("PhoneNumber", "555-5555"),
                   Element("Address", "Upda road 42"),
                   Element("Country", "England")))
   {}
}

All we've done is moved the methods into a class named DocumentWithHelperMethods. We can call them directly, with no prefix, from the constructor of the derived class. The only constraint is that, to call them from inside "base(..)", we must make them static methods. You can see a full example of this approach in one of the unit tests here.

7. Put extension methods on "object"

I haven't tried this, but I presume that if you defined Element, Comment etc as extension methods on "object" then the desired syntax would work anywhere (needing only a "using" of the namespace of the extension class). Ugly. (Update Feb 08: and it doesn't work anyway, since an explicit "this" would be required, which defeats the purpose).

Summary

I find that 2a often works well. Whenever the desired method name consists of more than one word, you can consider using the first word as a class name.

But there is no one-size fits all solution.

It's not Rocket Science

Finally, this has really just been a post about one simple thing: finding ways to make methods that can be used without prefixing them. As Anders Noras says, this feels like introducing new "keywords" into the language. While this can be useful (and might even be interesting) it's not necessarily a DSL.

It is not rocket science. We're just trying to use meaningful method names, with no prefixes. Years ago, when I moved from BASIC to Pascal, I was thrilled to discover that I could write my own functions that looked "just like the built-in ones". It seems ironic that it's now so much harder to write methods without prefixes!

Sparklines for WinForms

noreply@blogger.com (John Rusk) — Sat, 04 Aug 2007 05:18:00 +0000

I wanted a Windows Forms implementation of Edward Tufte's "Sparklines". I couldn't find one, so wrote my own.

It's just very basic at present. You provide it a collection of numbers, representing the data points to be graphed in a sparkline. You also tell it how many horizontal pixels to allocate to each data point, and how the total height of the sparkline in pixels. Then it renders the sparkline for you.

You can use the code as a WinForms Control (SparklineControl) or you can programatically render to any Graphics object you like, using SparklineReneder.

Here's the source code, and here is an example of using it. Please leave any questions as comments on this post.

Example:


public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();

        spark.Height = 20;
        spark.Renderer.PixelsPerElement = 5;
        panel1.Controls.Add(spark);
    }

    SparklineControl spark = new SparklineControl();

    private void button1_Click(object sender, EventArgs e)
    {
        List<int?> values = new List<int?>();
        foreach(string s in textBox1.Lines)
        {
            string trimmed = s.Trim();
            if(string.IsNullOrEmpty(trimmed))
                values.Add(null);
            else 
                values.Add(int.Parse(trimmed));
        }

        spark.Renderer.DataElements = values;
        spark.Invalidate();
    }

Want a good job in Wellington?

noreply@blogger.com (John Rusk) — Mon, 23 Jul 2007 09:06:00 +0000

Are you a good .NET developer looking for a job in Wellington, New Zealand?

My employer is currently looking for .NET developers (junior, senior or anywhere in between). We may also be interested if your skills are mainly in testing or business analysis.

What is the company like? Good! I'm very glad to recommend it. Skilled, friendly people to work with; great customer feedback.

As I've often suggested suggested in my agile blog, working in an IT services company is full of challenges and opportunities. We're addressing those challenges and opportunities unusually well.

If you enjoy working on successful projects, please get in touch via email. You can find my address on my other site, here.

Claytons Interception

noreply@blogger.com (John Rusk) — Sun, 08 Jul 2007 10:44:00 +0000

Ayende posted 7 different interception approaches for AOP in .NET. Here's one more...

...well, actually, it's a "cheat's way" to do interception. But, it's has proved to be useful in the real world and it avoids all of the disadvantages mentioned in Ayende's post.

It is "the interception you do, when you're not doing interception"(*). It simply means that you write your property getters and setters in such a way that "interception" is built right into the code. Here's an example from Mindscape LightSpeed:


public string DisplayName
{
  get { return _displayName; }
  set { Set(ref _displayName, value, "DisplayName"); }
}

The Set method can do whatever is required, both before and after it sets the actual value.

Pros:

Simple, understandable, debuggable. Can still use "new" to create objects (unlike some alternatives).

Cons:

Only works for properties. While properties are the main place where interception is required (at least in ORMs and related functionality) some people do want interception on methods too.

Another disadvantage is that you have to put the property name into the setter method. While this is not too bad if your objects are generated (just re-generate if names change) it's still a bit ugly to have string names in the code. I'm particularly uncomfortable with it if anyone is likely to rename the property (using Resharper's Rename feature for instance) while forgetting to also change the string name in the property setter. And, given Murphy's Law and human nature, forgetting probably is likely.

Property Name Solutions

What if you don't like that property name sitting inside the setter methods?

Rocky Lhotka put together a solution to the property naming problem. The solution is based framework code crawling back up the stack to find the property setter. In my own tests, that can be slow and, as Rocky notes, it can be broken by method inlining.

I have put together an alternative solution, which does not suffer from those drawbacks. It lets you write the code above like this (note that the property name string is not inside the setter method any more):


public string DisplayName
{
  get { return _displayName; }
  set { Set(ref _displayName, value); }
}

It works by leveraging the fact that the first parameter is a ref parameter. With a bit of managed C++, you can convert that ref param into a managed pointer. Then you can look at how far "into" the object it points, and use that to identify the property. (Technically, it identifies the field. But, if each field is used by one property, then we can easily associate field names with property names.)

Note that the managed C++ code is pure .NET code, marked as "unsafe" so that it can use pointers. It has to be written in C++, not C#, because while C# can use pointers, it cannot create one from a ref parameter.

You can find a full working implementation here. Please note that I am not a C++ developer. This was the first (and probably the last) managed C++ that I have written! While I have undertaken a number of tests to check the validity of this appoach, the fact remains that I'm not experienced in managed C++. Use at your own risk. Please post any questions below.

Update, Feb 08: I've posted an updated, re-written version here.

(*) Austrialian and New Zealand readers may recognise the theme in naming this post. It's based on Claytons, marketed many years ago as "The drink you have when you're not having a drink."

No More Development on My Side Project

noreply@blogger.com (John Rusk) — Fri, 29 Jun 2007 22:55:00 +0000

UPDATE April 2008: this is an old post. I have since released one small part of the product as an Open Source project. I have kept the ActiveSharp name, even though the empahsis has moved away from business rules and onto property change interception. The new implementation is, to a large extent, a ground up re-design of the old one. Both did property change notification, but the new one does it in a much better way. The rest of this post remains below, as orginally written.

Six months ago I posted an alpha release of a library for .NET development, called ActiveSharp. It's unique feature was a dataflow-style rules engine. (You specify the rules, system calls them at the right time.) It also included an ORM designed specifically for ease-of-use.

This post is to announce that I will not be developing ActiveSharp any further. I still have lots of ideas about it's future potential, including some useful unique features, but I simply don't have the time to develop them.

It has been an interesting journey - both in terms of the technology and in terms of trying to produce a significant product while also working full-time and raising a family. In the end, something had to give. The ActiveSharp website will be taken down shortly (so this is your last chance to have a look at it :-)

Implementing Workflow with Persistent Iterators

noreply@blogger.com (John Rusk) — Sun, 06 May 2007 03:39:00 +0000

Why do workflow tools use diagrams and XML instead of regular programming languages? It’s a good question. When it comes to the core programming tasks - looping, conditionals and abstractions - XML does a lousy job. (As Koz’s post on BPEL explains.) As for workflow diagrams, they're just a visual representation of the XML.

So why are smart people writing workflows in XML instead of Ruby, C# or Java? If we ignore marketing, hype and that fact that XML is "just so darn cool" , we’re left with one good reason. It is the "showstopper" that prevents workflow development in ordinary languages.

In this post, I’m going to describe that showstopper. I’m also going to solve it. With the solution presented here, workflows really can be written in ordinary languages.

By the way, the solution presented here is in C#. As far as I can tell it is not possible in Java. It might be possible in Python or Ruby...

The Problem

The problem is simple: workflows have really big pauses in them. The execution of a workflow may be paused for days, weeks or even months waiting for some external event. Normal programming languages don’t handle this well. Imagine a long routine which represented the logic for a particular workflow. You can’t suspend the method at the half way point, wait for three weeks (maybe even rebooting the machine while you wait), and then have it pick up exactly where it left off – resuming at the exact line where it paused, with all local variables exactly as they where before.

Update 3 Jun 08: This Microsoft posting confirms big pauses as the key driver behind the development of their Windows Workflow product.

Here’s a simplified example of the problem:


public void ReviewDocument()
{
    SendToReviewer();
    WaitForReviewersReply(); // might take weeks
    PublishDocument();
}

How do get the method to resume at the right place when the reviewer finally replies? You can’t just call the method again, since if you do it will start again from the beginning.

I believe this is why smart people are writing workflows in XML instead of real languages. They construct a representation of the logic in XML, and write a workflow engine which can (re)serialize that representation (complete with its internal state) at each pause in the workflow. When the wait is over, everything gets deserialized and it resumes where it left off.

Ironically, all this XML stuff is unnecessary in C# 2.0 and later – which leads us to the solution...

Solution: Part 1 – Persistent Iterators

In C# 2.0 and later, you really can get a method to stop and then resume where it left off. The secret is the new "yield" keyword. In .NET, a method with one or more "yields" in it is called an iterator.

Here’s an example. It returns "One" the first time it is called, "Two" the second, and "Three" the third:


public IEnumerable<string> Foo()
{
    yield return "One";
    yield return "Two";
    yield return "Three";
}

C# makes this possible with some special behind-the-scenes magic. But there’s a catch, all that magic happens in memory. It’s no use if we want a 3-week pause complete with system reboots.

To achieve our goal we have to serialize all that magic out to disk. We call the method once, serialize the iterator state to disk, then three weeks later we deserialize the iterator state and make the next call to the method.

That might sound difficult, but as it turns out, it’s not. Thanks to Microsoft’s implementation of "yield" (and the flexibility of .NET serialization) it only takes a few lines of code. Here it is in action:

Note that I ran the program three times. Each time it got the next value from the sample method. That confirms that state is being persisted outside the process, which means it can cope with arbitrarily long delays. You could run it today, and have it yield "One". Then you can reboot overnight and still have it yield "Two" when you run it tomorrow.

(Download source code.)

This is the first part of our solution: persist state between yields. (Update: See Microsoft's comments here).

Solution: Part 2 – Yield "When to Call Me Back"

Let's recap on what we've got. We now have a way to call a method, have it stop part way through, pause for a reeeeeealy long time, and then have it resume where it left off. That’s exactly what we need to solve our workflow problem.

There is only one more thing we need to figure out: what should the method return when it yields? Assuming that the method will be called by some hypothetical workflow engine, it should return something which tells the engine when to make the next call.

For instance, if the method needs to pause until 7:30 am, it should yield an object which says "Call me back at 7:30".

If the method needs to pause until data is updated for customer number 123, it should yield an object which says, "Call me back when customer #123 is updated".

This lets us write our workflow as a perfectly ordinary method, yielding only when a long pause is required.

There must be a degree of polymorphism in the yielded objects – since some of them represent a delay until a fixed time, some represent a delay until certain data is updated, and others may represent delays until users reply to system-generated emails and so on. There’ll also need to be some "smarts" in the engine to interpret theses objects appropriately – roughly equivalent to the logic in an ordinary XML workflow engine, although different in the implementation details.

At this point I must apologize, because I have not had time to put together a working example. If there is enough interest in this post, I’ll try to publish one in the future. In the meantime, here’s how you might write a simple workflow:


public IEnumerator<EventToWaitFor> Foo()
{
    DoSomething();

    // Ask the engine to call back in 5 hours
    yield return new TimeDelayEvent(new TimeSpan(5, 0, 0));

    DoSomethingElse();
}

To make this really workable, a little syntactic sugar may help. Therefore, in the next example, I have introduced a method called "Until", just to make things read more smoothly. Again, I must apologize for not having more time to explain this example, so please leave a comment below if I have failed to explain it properly.


public IEnumerator<EventToWaitFor> ApproveDocument(Document doc)
{
    do
    {
        // Initiate a review and yield (i.e. wait) until it is complete
        ReviewAction review = new ReviewAction("qa@example.com", doc);
        yield return Until(review.Completed);  // might take weeks

        // (omitted) ... email original author to notify them
        // of review outcome ...

    } while (!review.DocumentIsAcceptable);

    // Yield (i.e. wait) until scheduled publication date
    yield return Until(doc.PublicationDate);  // might take days
    PublishDocument(doc);
}

This is the second part of our solution: yield for large pauses, returning an object which says when to resume.

Conclusion

Modern programming languages express logic far better than XML. With persistent iterators, they can also handle the long pauses required in workflows.

At present, there is no production-quality workflow engine which supports this model. But perhaps there might be soon...

Update: see this - Microsoft may change implementation details that affect this approach. But they recognise the usefulness of the technique, so hopefully it will be a case of changing it, rather than breaking it.

Symbols Part 3

noreply@blogger.com (John Rusk) — Wed, 18 Apr 2007 09:36:00 +0000

Here's another alternative, which would unify lambda expressions and "symbols" nicely.

Also note that the solution in my previous post would be good for "mock" stype unit testings, since it works just fine in .NET 2.0 an later. It would allow you to specify method call expectations by writing the methods names directly into your code (rather than using string representations of their names).

Symbols, Part 2

noreply@blogger.com (John Rusk) — Thu, 12 Apr 2007 02:00:00 +0000

I've previously written about how useful it would be to have compiler-checked symbols in C#. It allows you to identify methods, properties etc without having to use uncheckable (and un-refactorable) string literals. Insteads, you can use the method or property name and have it checked by the compiler (and refactored by your refactoring tool.)

I have some good news and some bad news:

The good news: you can simulate named symbols for methods right now.

The bad news: the technique doesn't work for properties (which is probably where you want it most).

Anyway, here's now to get a "named symbol" effect for methods. It relies on delegate inference to let you to use a method name and have the system automatically create a delegate. (Inspecting the delegate then gives the method info, when you need it.)


// Declare a delegate for a parameterless method 
// which returns void
public delegate void SimpleDelegate();

// This is the method to which you want to pass other
// methods. Its param is typed as SimpleDelegate
// Return type can be void or whatever you want.  
// I've used bool just for the sake of the example 
// below 
protected bool DoStuffWithMethod(SimpleDelegate d)
{
   // here d.Method identifies the method
   ...
}
// Example of use:

// This is the method we want to refer to
public void Foo()
   { ... }

// here o.Foo is the compiler-checked "symbol"
MyObject o = new MyObject();
Assert.IsTrue(DoStuffWithMethod(o.Foo));

It would be great to have something similar for properties. Perhaps delegate inference could be extended so that if you use a property name instead of a method name, then the inferred delegate will point to the property's "getter" method.

P.S. as others have already pointed out, another solution for properties is to use LINQ-based syntax. Personally, I'd like something cleaner. I don't like the idea of writing "o => o.Foo" every time I want to say o.Foo (although I can't argue with the fact that it does work :-)

Finally, as noted here, a solution which worked in atttributes would be great (which is admitedly not the case for any of the solutions mentioned in this post).

Also see followup here.

Quoted Strings

noreply@blogger.com (John Rusk) — Tue, 10 Apr 2007 01:41:00 +0000

I posted this suggestion about an alternative form of @-quoted strings. It would be useful in cases where the string itself contains lots of double quotes.