[OT] What are D's values?

[H. S. Teoh]

On Mon, Oct 04, 2021 at 11:10:27PM +0000, Tejas via Digitalmars-d wrote:
[...]
> Can you please list any resources on DbI?
> 
> I've been finding it pretty hard to grasp, and I only managed to find
> a few videos by Andrei on the subject.
[...]

The basic idea is very simple (but the results are powerful indeed).

Basically, in traditional code, when a function takes a parameter, say,
it specifies exactly what the type T of the parameter must be (int,
float, some struct, etc.).  In the function body, it makes use of the
implementation details of this type in order to perform operations on
the data.

	auto myFunc(T data) { ... }

Experience shows, however, that often the function doesn't actually
depend on *all* the details of the type T.  Perhaps it uses only a small
subset of its fields/methods.  For example, the function may only need
to use .front and .empty.  So there's no reason for the function to
demand that incoming arguments must be of a fixed type T; T can really
be *any* type that happens to have a .front and .empty with the expected
semantics.  So we move from a normal (non-template) function to a
template function:

	auto myFunc(T)(T data) {
		... // make use of .front, .empty here
	}

So far so good, we all know what template functions are.

But DbI takes this one step further: suppose myFunc doesn't actually
need to use .empty. Maybe there's a different way to do what it wants
without using .empty, but it uses .empty because of efficiency (or
whatever other reason).  Still, since it's not strictly necessary, why
make the function depend on it?  It would be nice to be able to pass
types to myFunc that don't have .empty, so that it can perform its magic
(albeit somewhat less efficiently/whatever).  So what we do instead is
to use `static if` to inspect the incoming type T, and adapt ourselves
accordingly:

	auto myFunc(T)(T data) {
		static if (... /* T has .empty) {
			... // make use of .front, .empty here
		} else {
			... // alternative implementation that doesn't use .empty
		}
	}

Voila! Now myFunc can take both types that have .front and .empty, and
types that only have .front.

(Note also that this doesn't have to be limited to the presence/absence
of a field.  It can be any attribute of T inspectable at compile-time.
You can have static if blocks to switch between implementations based on
the size of a type, for example to make decisions about how to best
allocate storage for a large number of its instances, say. Or, the
favorite among D users, make decisions based on some UDA that you attach
to the type in order to change how the function processes it.)

This may seem trivial, but it has powerful consequences.  By making
myFunc independent of the existence of .empty, we've increased its scope
of applicability to a wider set of types.  Each static if we introduce
more-or-less doubles the set of types for which the function is
applicable.  Instead of writing one function for types that have .front
and .empty and another function for types that have only .front, we can
process both according to the same logic.  Instead of demanding the
caller of the function to supply us with a type fulfilling requirements
A, B, C, we adapt ourselves to whatever type the caller may throw at us,
making use of compile-time introspection to discover what the type can
do and adapting ourselves accordingly.

//

An actual example I wrote myself: a serialization module I wrote for
writing out objects into text form and reading it back later to
reconstruct said objects.  Instead of the traditional method of
inserting a .serialize method into every struct and class (wayyyy too
tedious, repetitious, and highly prone to bugs caused by human error),
my code instead does this:

	void save(S,T)(S storage, T data) {
		static if (is(T == struct)) {
			... // serialize structs here
		} else static if (is(T == class)) {
			... // serialize structs here
		} else if (is(T == U[], U)) {
			... // serialize arrays here
		} else if (is(T : int)) {
			... // serialize int-like types here
		}
		... // etc
		else static assert(0, "Can't serialize type " ~ T.stringof);
	}

So, when I want to serialize a struct S, what do I do?

	S data;
	storage.save(data);

When I want to serialize an int?

	int data;
	storage.save(data);

When I want to serialize an array?

	S[] data;
	storage.save(data);

Super-easy.  Notice that I deliberately named my data `data`: that means
if I ever decide to change the type of my data, I don't even need to
edit the .save line; I just change the type of `data`, and .save Just
Works(tm).  It automatically adapts itself to whatever type is passed to
it.  No need to call a different function, pass a ton of flags, none of
that fuss and muss.  Just hand it a different type, and it Just
Works(tm).

But wait, there's more!  What if I want to treat strings differently
from other arrays?  Easy, just add a static if block to .save that
handles strings before it handles general arrays:

	void save(S,T)(S storage, T data) {
		static if ...
		... else if (is(T == string)) {
			... // special handling for strings here
		} else if (is(T == U[], U)) {
			... // handle general arrays here
		} else ...
	}

But what if I want a different serialization scheme for certain data
types? E.g., if I have a struct MyStruct, and I don't want to serialize
*all* fields, but want to exclude, say, fields that only store cached
data that can be recomputed next time?  Here's where UDAs come into
play: I mark fields I don't want to save with a special UDA:

	struct DontSerialize {}

	struct MyStruct {
		int i;		// save this
		float f;	// save this too
		@DontSerialize string s; // don't save this
	}

	void save(S,T)(S storage, T data) {
		...
		static if (is(T == struct)) {
			foreach (field; allMembers!T) {
				// skip fields tagged with DontSerialize
				static if (!hasUDA!(mixin("data."~field), DontSerialize)) {
					... // serialize here
				}
			}
		}
		...
	}

Notice how clean this is.  In a traditional approach, I'd have to pass
some kind of blacklist to .save, perhaps an AA of stuff I don't want to
save, or some boolean flags, etc..  But with DbI, the API of .save
remains exactly the same as before:

	MyStruct[] data;
	storage.save(data);	// <--- exactly the same as before

All I need to do is to tag the field in the definition of MyStruct -- no
need to change code in all the places that pass MyStruct to .save, no
need to change the API of .save (or, God forbid, add a new overload /
different function just to handle this case), just add a new static if
block to check for the UDA, and it Just Works.

In other words, adding a new static if block to .save "teaches" it how
to adapt to structs that contain fields that shouldn't be saved. Once
thus taught, you can just hand it any type appropriately tagged with the
UDA, and it automatically does the Right Thing(tm).  No fuss, no muss,
no extra parameters, no messy option flags, no massive refactoring of
every callsite of .save, just a couple of lines of code change and we're
done.

There's so much more you could do to it. For example, another UDA for
tagging types that should use a different serialization scheme (e.g.,
highly-compressible data that should be filtered through a compression
algorithm). Another UDA that filters an array to exclude elements that
don't need to be saved.  Etc..  With every addition, .save becomes more
and more powerful, yet its API remains exactly the same as before:

	storage.save(data);	// <--- exactly the same as before

Code that calls .save don't need to be touched just because some data
type now needs different serialization behaviour. No massive
refactorings needed, no proliferation of flags and other extraneous
parameters to .save.  Just tag the type definition, and we're good to
go.

This, my friend, is the power of DbI.  This example, of course, only
scratches the surface of what you can do with DbI, but I'll leave it up
to you to explore the rest. :-D


T

-- 
Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln