views:

253

answers:

1

I have been looking at DbC lately and Spec# which seem to have support for non nullable objects. Unfortunately Spec# seem to have been abandoned.

  1. Spec# seemed to have lots of nice language features built in so why was it abandoned?
  2. Would there be any problem with letting all objects be non-nullable by default so you would have to write int?, string? and even MailMessage? if you really wanted a nullable object?
  3. I see kind of a Sql analogy here where you could check class properties as nullable or non nullable. Could you even put constraints on properties as you can with sql table columns?

I don't see the problems with having features like this built in to the language. Could anybody enlighten me on this?

+6  A: 

Have you seen the new Contracts framework will will be part of .NET 4.0?

The benefit of making it a library rather than language feature is that it becomes immediately available in all languages, with no work on the part of the language teams. Obviously there are disadvantages too...

Links:

Having said all that, I'd like to be able to write:

public Stream! Foo(string! x)

as well, indicating that Foo must not receive a null reference, nor will it return one. Having an extra bit of syntax for just that type of contract would be handy, I think.

Jon Skeet
I have seen it and it seems to have the disadvantage of less compiler checks and more bloated code. Maybe they could have shipped this built in to c#4.0 and offered the framework for the other languages?
TT
While the checks aren't done at compile time, they *are* done as a post-build step, so it's not like you have to wait until you're actually running the code. It'll be interesting to see how well it works, but I'll be happy to have it at all, to be honest.
Jon Skeet
Thx for the links. I saw the PDC video and I can imagine me using the Contract Framework a lot. Still Spec# looked a lot nicer :)
TT
Well the good news is after the framework for the contacts lives under the covers the language teams could define new syntax (such as the fantastic Spec# patterns) and have the checks done by the compiler. After all "from a in myObjects where a.IsProp select a.Name" is compiled into myObjects.Where(a=>a.IsProp).Select(a=>a.Name) ... Even that is nicer than what the real static calls would look like with out extensions methods.
Matthew Whited