How much code do you write, how many bugs occur because one of your objects is null, not set by some piece of code? How many lines of code includes, if (this!=null) etc ? I have seen my fair share of null reference exceptions and you have probably too.
So with Null Reference Exceptions being a very big part of development still, we really do need a way to combat it better. One way I believe would help is by giving us the opportunity to have Accessors on an Object. Just like we have a Constructor, the Accessor, should have the same name, but contain a get and set declararion.
The main reason is to inform us, of when our object is being set. Accessors on Properties is now normal, and I thinks its about time we get Accessors on Objects, where we still do not have any events to tell us when its been replaced by another. if you write the following code, you wont know it happened as it happens. No event is fired.
myobj.Name = "Name" // you know when this happens. In the Set accessor of the property
myobj = yourobj; //BUT how will you know this happened?
below is how I think the syntax should be.
class Class1
{
public Class1() // Constructor has same name as class
{
}
public Class1 // Accessor has same name as class
{
get
{
return this; //default behaviour, which we could change,
//to return a base type, a different instance or other
}
set
{
//If its not null, we set this,
//else we can do something else, throw an exception
if (value!=null)
this = value;
}
}
}
Consider, that we spend a lot of time and a lot of lines of code, writing if statements to check if objects are null or not null. Consider when you have a collection or array within your class, you often set it, initialize it to an instance in your constructor. as in
array = new ArrayList().
You do this so that the object does not have a chance to be null when someone writes
myobj = new MyObj()
myobj.Array(0); //which will fail if you have not created a new instance
So firstly from a Null reference point of view and cleaning up null checks within our code, the Object Accessor could be helpful.
Return Base Type or Proxy at will
It can also be useful for polymorphic behaviour within abstract factories design pattern or similar uses. Allowing you to 'substitite' 'this' by saying this = someOtherInstance, would offer good flexibility.
As long as the Type we return is a base type of the Type, we can then return other classes within the hierarchy.
Extension Methods
Lastly, since we can set the this keyword, it would make Extension methods a little nicer too.
public static class XmlCategoryReader
{
public static void Read(this Category obj, string filename)
{
obj = new Category(); //WHY NOT? :)
}
}
Why Not?
The fact that the keyword 'this' may refer to a different interface is perhaps a problem, but it can surely be overcome. if Duck Typing was introduced, it may play well here, or at least this would be another extension point for it.
Tags: