Non-null objects, the Null Object pattern, and T.init

Rikki Cattermole alphaglosined at gmail.com
Thu Jan 16 17:57:23 PST 2014


On Friday, 17 January 2014 at 01:42:38 UTC, Andrei Alexandrescu 
wrote:
> Walter and I were talking today about the null pointer issue 
> and he had the following idea.
>
> One common idiom to replace null pointer exceptions with milder 
> reproducible errors is the null object pattern, i.e. there is 
> one object that is used in lieu of the null reference to 
> initialize all otherwise uninitialized references. In D that 
> would translate naturally to:
>
> class Widget
> {
>     private int x;
>     private Widget parent;
>     this(int y) { x = y; }
>     ...
>     // Here's the interesting part
>     static Widget init = new Widget(42);
> }
>
> Currently the last line doesn't compile, but we can make it 
> work if the respective constructor is callable during 
> compilation. The compiler will allocate a static buffer for the 
> "new"ed Widget object and will make init point there.
>
> Whenever a Widget is to be default-initialized, it will point 
> to Widget.init (i.e. it won't be null). This beautifully 
> extends the language because currently (with no init 
> definition) Widget.init is null.
>
> So the init Widget will satisfy:
>
> assert(x == 42 && parent is Widget.init);
>
> Further avenues are opened by thinking what happens if e.g. 
> init is private or @disable-d.
>
> Thoughts?
>
>
> Andrei

I am assuming init will be a property static function. So 
essentially we would be removing .init support for classes in 
compiler and pushing it out into Object.

I would rather if that is an option an init static function, that 
it would be required to have override otherwise it would be too 
'magical' for me atleast.
The default can still be null.


More information about the Digitalmars-d mailing list