musings on hybrid CT/RT tests, some more progress on new web framework

Posted 2019-06-03

New LDC beta, GtkD updated (and now uses adrdox for their official docs!!), and I think about CT/RT hybrid tests as well as some more progress on my new web framework.

Core D Development Statistics

In the community

Community announcements

See more at the announce forum.

Tip of the Week

Ever since Andrei Alexandrescu mentioned considering unittests as being an extension to compiler semantic checking, I have been getting increasingly excited about the potential for hybrid compile-time/run-time tests.

With normal compile time checks, you need all the data to be together in one expression. You might pass things to helper functions from different parts of the program, but it all ultimately needs to make its way down to just one expression to actually static assert on.

But, what if you have two fairly isolated components that nevertheless need to test together? Well, that's where you can do the hybrid tests: gather information at compile time, generate static constructors to bridge the gap from there so you can test it at runtime. Static constructors or unittests can assert on tables made in other modules at compile time.

I am just starting to explore this, and I suggest you do too. Talk about it on the forums or email me (destructionator@gmail.com) if you find anything cool with it!

What Adam is working on

I am always bouncing around projects, so sometimes many months go by before I am able to continue something. I finally just improved the new cgi.d dispatcher, after been wanting to do that for the better part of this year.

I wanted to make that url dispatcher work entirely off CTFE data, but I also wanted a presenter object passed to it. This has to be fully templated to use all the CT data, and it took me forever to think of my plan... but I think I finally have it.

dispatcher is now a IFTI template nested inside a variadic template, and you can pass your own presenter to it. Everything inside is then templated on that, and pass types to this item, specifically, as necessary to figure things out.

When you define your own item, you need to match the signature and provide fallback templates.

1 class MyPresenter : WebPresenter!() {
2         void presentSuccessfulReturnAsHtml(T : FakeType)(Cgi cgi, T ret) {
3                 // handle my new FakeType
4         }
5         void presentSuccessfulReturnAsHtml(T)(Cgi cgi, T ret) {
6 		// generic fallback
7                 super.presentSuccessfulReturnAsHtml(cgi, ret);
8         }
9 }

(You don't actually have to inherit, and it doesn't help too much in getting the signature right, but meh.)

This will let us centralize various policies for the application.

Still a long ways to go, but most progress I have made here for a little while.