kamagra how much to take

Non-null types in Spec#, Spec# Part 1

I guess I should prefix this post with a warning. Spec# is an experimental language, an extension of C#. I am not advocating it for production use, it is maintained by Microsoft Research, and unless you are silly like me and do it for some clients after advocating its focus on design quality and why DbC programming is important to consider for software design principles, just use it for fun. Anyways, let’s get started. This post is going to focus on the what I consider a very important feature of Spec#, extending the type system to include non-null type fields.

We are aware that Spec# allows us to focus on non-null type fields, and more importantly, Spec# allows us to heighten quality of the software that we develop because of it’s focus on DbC programming paradigms. Checking for null-related errors in C# at compile time is very important because when declaring objects, not limited to just our argument of C# but in OOP language in general, there must be distinguishing mechanisms that differentiates null objects, or special null objects, from declared objects. Because of the difference between a null object, and a declared (or proper) object, certain compensation normally has to be considered during the code practice, indeed, a reference type variable being null is very, very common.

Retrofitting our OOP language of choice, C#, makes sense to equip with this functionality, as in the class constructors, where there may exist fields which are non-null and possibly not yet initialized, however still usable is the partially constructed object. Ideally, we could use a type-based method, that at compile-time would detect these null pointer violations within the code. Best case possible (and hopefully something that might be considered for this type of paradigm within the future), would be an inference engine that would take legacy code files and convert them to harness the non-null type functionality.

Basically, a way to where we are automatically retrofitting legacy code within minimal developer interaction. In order to do this, I suppose there would have to be a level of static semantic analysis that code take the source code as a parameter and output the relevant non-null compliant counterpart.Ok, so now what knowledge are we now equipped with? We now know that non-null types are targeting problems that currently arise in class constructors, where non-null fields may not yet have been initialized, leading to null-related errors. We need a way to distinguishable declared objects from null objects, or special null objects. We know that this is important because null values generally have to be handled differently than properly declared objects. But what does Spec# have to do with this whole thing?Since we are checking for null references, there are several ways to decorate code so that the Spec# compiler will consider it to be acceptable. The first is we can explicitly decorate the statement for a null check. This is pretty easy:

  1. SPList mylist = web.Lists[listGuid];
  2. SPListItem itemById = list.Items.GetItemById(id);
  3. if (itemById == null)
  4. {
  5. throw new NullArgumentException();
  6. }

We can do this even more simply, by going:

  1. SPList mylist = web.Lists[MyList];
  2. SPListItem itemById = list.Items.GetItemById(id);
  3. if (itemById != null)
  4. {
  5. // now I do something
  6. }

However, in Spec# we can use a concept called a precondition, however because we are satisfying the above with the appropriate null reference checks it will satisfy enough in order to compile through the Spec# compiler. A precondition is engined by a built-in theorem prover.As we have talked about, the Spec# compiler will enforce method contracts, a caller and the implementation of a method, and we are enhancing the type system to include non-null types (which are, inherently a part of an DbC programming paradigm). A precondition, although not an arbitrary amount, can implement many data types, and help to state proof obligations within code. As the name implies, a precondition will specify certian conditions, such as the state of the object in question as well as method parameters that being consumed, before the actual method is called. If a method violates the preconditions that are set, there will be a “precondition violated from method” error thrown at compile time, preventing compilation of the actual binary or executable. Now, let’s take the concept of preconditions into our SharePoint code above.

We started out with this:

  1. SPList mylist = web.Lists[MyList];
  2. SPListItem itemById = list.Items.GetItemById(id);

and we were able to bypass Spec# compiler errors with some standard code decoration. In order to compile with Spec# using preconditions, you could take one of two approches, either using the requires keyword, or using the Bang, !, symbol. If we wanted to use the requires keyword, we could simply do a

  1. requires itemById != null;

We could also use the bang symbol

  1. SPListItem! itemByID;

In the next post, we will look at a simple console application that we will retrofit some code to Spec# adherence, examining some familiar code to understand how exactly this entire process works. We will firstly build a simple C# Console application that will enumerate through a set of SPWeb objects contained in a site collection. In normal C# world, this looks like this in code (since I would not want to advocate bad practice code, I will use the appropriate using keywords to take into OM object disposal):

  1. using System;
  2. using System.Collections.Generic;
  3. using System.Text;
  4. using Microsoft.SharePoint;
  5.  
  6. namespace noSpecSharpApp
  7. {
  8. class noSpecSharpApp
  9. {
  10. static void Main(string[] args)
  11. {
  12. using (SPSite mySite = new SPSite("http://localhost/"))
  13. {
  14. foreach (SPWeb returnWeb in mySite.AllWebs)
  15. {
  16. Console.WriteLine(returnWeb.Title + " " + returnWeb.Webs.Count.ToString());
  17. }
  18. Console.ReadLine();
  19. }
  20. }
  21. }
  22. }

Which will see how to retrofit to a Spec# application, and all the fun null exceptions that will throw along the way.

I am tired now, and don’t feel like writing about Spec# anymore. Stay tuned for the next part where we start to tap into the SharePoint OM using Spec#.

share save 171 16 Non null types in Spec#, Spec# Part 1

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>