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

[H. S. Teoh]

On Fri, Jan 17, 2014 at 12:51:38PM -0000, Regan Heath wrote:
> On Fri, 17 Jan 2014 05:29:05 -0000, H. S. Teoh
> <hsteoh at quickfur.ath.cx> wrote:
> >Now, if we modify this sentinel to instead record the location of the
> >code that first initialized it (via __FILE__ and __LINE__ default
> >parameters perhaps), then we can set it up to print out this
> >information at a convenient juncture, so that the source of the
> >uninitialized reference can be determined. *Then* perhaps it will be
> >a start of a solution to this issue. (Though it still has limitations
> >in the sense that the problem can only be caught at runtime, whereas
> >some cases of null dereference preferably should be caught at
> >compile-time.)
> 
> So.. if we had a base class for all objects which obtained the file
> and line when created by assignment (from init) and threw on any
> dereference (opDispatch) that would do it, right?
[...]

If Andrei's proposal were extended so that .init can be overridden by a
member *function*, then this would work:

	class NullTracker {
		override typeof(this) init(string _file=__FILE__,
						size_t _line = __LINE__)
		{
			class Impl : NullTracker {
				string file;
				size_t line;
				this(string f, size_t l) { file=f; line=l; }

				override void method1() { nullDeref(); }
				override void method2() { nullDeref(); }
				...
				void nullDeref() {
					// N.B.: puts the *source* of the
					// null in the Exception.
					throw new Exception(
						"Null dereference",
						file, line);
				}
			}
			return new Impl(_file, _line);
		}

		void method1() {}
		void method2() {}
		...
	}


T

-- 
People walk. Computers run.