Of course I would never hit a beautiful, charming and intelligent man like myself but I sometimes think about it. Especially if I do stupid things like this.

You get this error if you do that.

System.ArgumentException: Form showDialog tried to set an ineligible form as its owner. Forms cannot own themselves or their owners.
Parameter name: owner

Makes perfect sense. So don’t ever do that again. The good thing is that there is an exception for this, so someone did this before.

YEEEEEEEEEEEEHA the spelling checker didn’t like that one), here are some of the new features in VB 10.
And yes, I did sound happy there, because some of these features are really not optional but much needed. Like the multi-line lambda and the sub lambda.

You can find the whole video on Channel9

Multi-line lambdas will look like this

Or like this

Now this will also be possible. And I’m very happy about that.

They will also support auto properties and collection initializers, neither of which I really needed.

I’m so happy, I think I will stick with VB for a while. Although all the catching up to C# thing is annoying. I just hope it doesn’t become a VS 2011 or later version. Let’s make it a VS 2010 that came out in 2009 version shall we?

And here is some other stuff that should be possible.

Info found after some random surfing on StackOverflow

Introduction

If you have been using an OO language to program with then you should have heard of the Law of Demeter. If you haven’t then you should read some of the articles I collected on Google.

• Wikipedia
• The Paperboy, The Wallet, and The Law Of Demeter by David Bock
• Introducing Demeter and its Laws
• Entities and the Law of Demeter by Jimmy Bogard

Definition

It is actually very simple to me. But explaining it can be a bit more daunting. This is what you can find on Wikipedia about it.

When applied to object-oriented programs, the Law of Demeter can be more precisely called the “Law of Demeter for Functions/Methods” (LoD-F). In this case, an object, A, can request a service (call a method) of an object instance, B, but object A cannot “reach through” object B to access yet another object, C, to request its services. Doing so would mean that object A implicitly requires greater knowledge of object B’s internal structure. Instead, B’s class should be modified, if necessary, so that object A can simply make the request directly of object B, and then let object B propagate the request to any relevant subcomponents. Or A should have a direct reference to object C and make the call directly. If the law is followed, only object B knows its own internal structure.

More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:

1. O itself
2. M’s parameters
3. Any objects created/instantiated within M
4. O’s direct component objects

In particular, an object should avoid invoking methods of a member object returned by another method. For many modern object oriented languages that use a dot as field identifier, the law can be stated simply as “use only one dot". That is, the code “a.b.Method()” breaks the law where “a.Method()” does not. There is disagreement as to the sufficiency of this approach.

My side of the story

Let’s oversimplify this a bit. When you see 2 dots in a statement, then you know something is going to be wrong. Look at this:

In that example _Person.Addresses.Count is a smell. Why? Because Addresses could be null and when it is null it can give a nullreferenceexception and crash our program.

There are 2 ways around this problem.

First.

or

What is wrong with this approach? Well every time you call Addresses.Count you have to check if Addresses isn’t null and print 0 instead. This gets boring very quickly and sometimes somebody might forget this little detail.

So we have a better solution. Namely, add a Method/Property to our Class Person. We name it CountAddresses for example and it would look something like this.

Now we can call CountAdresses instead of Addresses.Count and not have to fear NullReferenceExceptions anymore.

The downside of this is that you have to write more code in your classes. But less code in your calling classes.

So I guess you should use it wisely.

When not

And when doesn’t the Law of Demeter apply?

• Fluent interfaces (Unlimited amount of dots)
• Factory classes (You can have 2 dots there)
• Legacy systems (No laws apply in there)

There is no bug in Rhino mocks if that’s what you’re thinking. Rhino mocks 3.5 just uses things that VB.Net 9.0 can’t use and that can be frustrating. I wonder what possessed them to do it like that?

So let me tell the story.

I got a service and a repository, the service calls the repo.

Repo interface:

The repo implementation:

The service interface:

The service implementation:

And now we want to test it.

First, we test the service’s findall method. We mock out the repo and see if the repo was called.

This works just fine.

Now I want to see if the update method is also used as it should be, so I write this:

But that gives me an error “Expression does not produce a value.". Mmmm, you can find an explanation for that here. And the solutions is there as well. The solution is, however, a bit clunky, as he says.

So in the end you could do this:

Which solve the problem, more or less.

So, last week Ayende made a new version of Rhino Mocks available, namely version 3.5. He made a post on what is new and shiny, but I would like to look at what the new AAA syntax has in store for us VB.Net users.

And I want to tell you how it used to look and how it looks now.

This is the old version, works with Rhino mocks 3.4.

Ok, so we notice the use of _mocker and DynamicMock to create our Mock objects and then we set our expectations, then we do a replayall and execute the methods under test. When the test is done the verifyall is executed which looks if our expectations are met.

Now we switch to Rhino mocks 3.5 and see that we get an error on Expect saying that the signature is not correct. No worry this is because it is choosing the wrong Expect. It is namely trying to use the extension method there. Just add Rhino.Mocks. before the Expect and all is well again. Look how the imports doesn’t do the same thing.

And now on to the new.

Look at how the _mocker.DynamicMock are replaced by MockRepository.GenerateMock and how the _mocker object has disappeared all together. The Expect.Call’s have been replaced with Object.Stub methods. And the ReplayAll and VerifyAll are now gone. Overall, a bit simpler and more meaningful.

Here is another good article about the use of AAA and Rhino mocks but then in C#.

And it only goes to show that even the smartest and best people don’t get it right the first time .

Ayende asked to add this to his wiki and so I did http://ayende.com/wiki/Rhino+mocks+3.5+and+VB.Net+the+AAA+syntax.ashx