Nullability is a feature that allows you to specify whether or not something can be null. This is useful because it allows the language to enforce that access to a field or method is via a non-null value. This should make NullPointerExceptions a thing of the past!<\/p>\n
In fact, the only place in plinth where you might get a run-time error because of a null value is when you cast from a nullable type to a not-null type.<\/p>\n
Let’s start by looking at some of the things we can and can’t do with nullable values (the Before I implemented nullability in Plinth, every type was not-null, including custom type definitions. The main thing you need to consider with not-null fields is that they have no default value; this makes plinth’s default behaviour very different from most major object oriented languages.<\/p>\n Because some fields have no default value, they must be initialised before the end of the constructor. In fact, they must be initialised before the newly allocated object could possibly be accessed from outside the constructor. This means that, until all of the fields of So far this is all fine, but what happens when we have two (or more) classes which need not-null references to each other? This problem is difficult to solve, for a number of reasons. I’ll use the following as a very simple example:<\/p>\n Obviously, in this scenario, one of the constructors must always be run first. This seems like it makes it impossible to create either of them, but let’s suppose that we have a way of allocating an object without calling its constructor. When an object has just been allocated, it’s still ‘uninitialised’ until its constructor has been run. Now, if we could pass an uninitialised object into another constructor, we might be able to do something like this:<\/p>\n But now we have more problems. B’s constructor can’t let Now, we know exactly what isn’t allowed to escape: ‘this’ and ‘a’ (we only allow uninitialised parameters in uninitialised constructors). Then, once we’ve created Next, we call the constructor on This scheme is based loosely on some discussions with and papers recommended to me by James Elford, in particular the Freedom Before Commitment paper[1]. However, it is not yet anywhere near implemented in plinth, for several reasons:<\/p>\n That said, this cyclic initialisation scheme is something I would very much like to implement eventually, once all of the problems with uninitialised variables have been well-thought-out.<\/p>\n The slightly ugly workaround which can be used until this scheme is implemented is to have a nullable field and a property to access it. This will give a run-time error whenever a field is accessed on a not-properly-initialised object:<\/p>\n Next week’s post will talk about binary compatibility, and how objects in plinth are represented in LLVM bitcode.<\/p>\n?:<\/code> and ?.<\/code> operators are based on those in languages like Groovy):<\/p>\n\/\/ casting between null and not-null values:\r\nFoo foo = new Foo();\r\n?Foo nullable = foo;\r\nFoo notNull = cast<Foo> nullable; \/\/ throws a run time error if nullable is null\r\n\r\n\/\/ accessing fields and methods:\r\nstdout::println(nullable.someText); \/\/ error: cannot access a field on a nullable object\r\nnullable.doSomething(); \/\/ error: cannot call a method on a nullable object\r\n\r\n\/\/ the null coalescing operator (giving a default value):\r\n?uint index = null;\r\nuint notNullIndex = index ?: 0;\r\n\r\n\/\/ the null traversal operator:\r\n\/\/ (the result is always null if the left-hand-side is null)\r\n?string str = null;\r\n?string subString = str?.substring(0, 2); \/\/ method call (the arguments are only evaluated if str is not null)\r\n?#[]ubyte bytes = str?.bytes; \/\/ field access\r\n?{string -> boolean} equalsFunc = str?.equals; \/\/ method access<\/pre>\nthis<\/code> have been given values (or have default ones like zero or null), the value of this<\/code> cannot escape the constructor. In plinth, making sure of this amounts to stopping people from using this<\/code> (except for things like\u00a0this.field = value;<\/code>) and stopping people from calling non-static methods.<\/p>\nclass A\r\n{\r\n B b;\r\n this(B b) \/\/ <-- constructor\r\n {\r\n this.b = b;\r\n }\r\n}\r\nclass B\r\n{\r\n A a;\r\n this(A a)\r\n {\r\n this.a = a;\r\n }\r\n}<\/pre>\nuninitialised A allocA = alloc A;\r\nuninitialised B allocB = new B(allocA);\r\nA a = new (allocA) A(allocB); \/\/ creates an A inside allocA, like C++'s placement-new operators\r\nB b = allocB;<\/pre>\n
this<\/code> escape until all of the fields are initialised, but now after it’s done this.a = a;<\/code> it can do whatever it wants, including letting ‘this’ escape and trying to access data inside a (which still hasn’t been initialised yet). We need to mark that the constructor can take certain uninitialised values, and then make sure that it can’t let ‘this’ escape even after everything’s been initialised. We could do this with an ‘uninitialised’ modifier:<\/p>\nclass B\r\n{\r\n A a;\r\n uninitialised this(uninitialised A a)\r\n {\r\n this.a = a;\r\n }\r\n}<\/pre>\nallocB<\/code>, we know that it being initialised depends only on allocA<\/code> being initialised, since it is the only uninitialised argument.<\/p>\nallocA<\/code>, to produce\u00a0a<\/code>\u00a0(A’s constructor will have to be modified the same way as B’s). We now also know that allocA<\/code> being initialised depends only on allocB<\/code> being initialised. We know the dependency cycle! All that we need to do is find the solution which makes the most things initialised\u00a0(i.e. the\u00a0greatest fixpoint of these simultaneous equations). Then we will know that both of them are initialised, thus allowing the assignments to a<\/code> and b<\/code>.<\/p>\n\n
class A\r\n{\r\n ?B realB;\r\n property B b\r\n getter { return cast<B> realB; }\r\n setter { realB = value; };\r\n\r\n this()\r\n {\r\n }\r\n void setB(B b)\r\n {\r\n \/\/ this method is only necessary if we make property's setter private\r\n this.b = b; \/\/ calls property setter\r\n }\r\n}<\/b><\/pre>\n