This Week in D October 25, 2015

Welcome to This Week in D! Each week, we'll summarize what's been going on in the D community and write brief advice columns to help you get the most out of the D Programming Language.

The D Programming Language is a general purpose programming language that offers modern convenience, modeling power, and native efficiency with a familiar C-style syntax.

This Week in D has an RSS feed.

This Week in D is edited by Adam D. Ruppe. Contact me with any questions, comments, or contributions.

Statistics

Major Developments

This Week in D is now featured on the dlang.org homepage!

LDC 0.16.0 has been released! This is based on 2.067.1 frontend. Also has Win64 compiler available!

DConf 2016, Berlin: Call for Submissions is now open! DConf 2016 will be hosted by Sociomantic Labs in Berlin, Germany, on May 4-6, 2016. They are now looking for talk submissions (an accepted talk will also mean the D Foundation will reimburse reasonable travel expenses to the conference). The submission deadline is February 26.

Job Openings

Two new openings at EMSI (D experience a plus) - Data Engineer and API Developer, Moscow, Idaho

Sociomantic Labs is looking for Software Developers! (D language), Berlin, Germany

In the community

Community announcements

See more at the announce forum.

Tip of the Week

D's structs are a remarkably flexible part of the language and can enable more than you'd think at first glance. This week, I want to show you a trick I used in dom.d to beat Javascript on style.

	struct Style {
		string* _attribute;
		ref string getAttribute() { return *_attribute; }
		alias getAttribute this;

		string opDispatch(string name)(string v = null) if(name != "popFront") {
			name = camelCaseToDashes(name); // dot notation is camelCase, css style is camel-case
			if(v !is null) {
				// parse the attribute, return the requested component
				return null; // not implemented in example
			} else {
				// set the component in the string
				return v;
			}
		}
	}

	class Element {
		string styleAttribute;
		@property Style style() { return Style(&styleAttribute); }
	}

	void main() {
		auto element = new Element();

		element.style = "color: red; font-style: italic;";
		assert(element.style.color == "red");
		element.fontStyle = "bold";
		assert(element.style == "color: red; font-style: bold;");
	}
$(P This code is incomplete, the actual guts of the logic is left unimplemented, but the purpose of this is to show the language technique, not the details of how to parse CSS strings, etc. Nevertheless, from the assertions, you get the idea of what's possible. (If you are interested in those details, I did implement this in dom.d)

The basic idea is to write a struct which gives custom functionality, then use alias this subtyping to fall back on another type for additional functionality. Sometimes, you may want to alias this to yet another wrapper struct to provide even more fine-grained customizability.

The Style struct here is not really intended to be used as a traditional plain-old-data type; the end user would never declare one themselves. (Indeed, it arguably ought to be a Voldemort type - a struct declared inside the style function itself, and returned with auto, such that its name is never spoken outside the function. Personally, though, I don't like that pattern. It comes with a few tradeoffs including forced templating - which doesn't play well with virtual functions in interfaces and classes - different documentation (some believe it is worse, I'm personally on the fence, but it is undoubtedly different than many programmers are used to), and just a bit of a pain to peer inside.)

Instead, the user simply calls the style method/property and pretends it is data that just happens to exhibit some interesting behavior. Here, the opDispatch provides a way to manipulate the string in a structured way, without the programmer needing to create code for the whole structure.

The constraint, if(name != "popFront"), on my opDispatch is there so the style property will never be accidentally mistaken to be a range by other compile-time duck typing. This is arguably a bit sloppy, but it works to prevent strange code from compiling and doing wrong things like infinite looping when, for example, writeln thinks it is an input range instead of a string.

The alias this does two things: for one, it provides a transition path for code that was previously written assuming style would just be a string. If you treat it like a string, it still works the same way, so that old code will not necessarily break. (Though, since it no longer is a string, templates can detect the difference, so such tricks are not foolproof.) The second thing is it enables something Javascript cannot do: the same getter can return a string or a style access object, depending on how it is used. We beat Javascript on style! :D 

	auto style = element.style;
	style.color = "green"; // works, the above got us the smart object

	string s = style; // still works, alias this makes it compatible with a string too!

The bottom line here isn't any one struct-based technique, it is just the realization that with wrapper structs and smart subtyping, we can apply *any* struct-based techniques to basic types, without needing to surrender the simplicity of working with that basic type directly when we want to.

Sometimes, a single struct cannot solve a problem, but creative combining of two or more may be able to. Don't give up when faced with a new challenge!

Learn more about D

To learn more about D and what's happening in D: