>
> > Indeed, I would argue is that reflection + injection, properly
> implemented, might well be able to make *every* design pattern obsolete —
> if it qualifies as a "pattern" in any sense, that means it is some call to
> a metafunction, and the only question is whether the programmers themselves
> must serve as that "metafunction", or if they are allowed to just write
> that metafunction explicitly and grab a beer.
>
> Well, yeah. Design patterns *are* obsolete in some more powerful
> languages; instead of being recipes for implementing
> patterns in various ways with various trade-offs, they're just code
> where those trade-offs are customizations points of the algorithm. :)
>

I've been known to say that design patterns are just workarounds for
missing language features :) It's entirely accurate, but it gets good
mileage.


> I would thus argue the best source for generating examples is thus any
> design pattern textbook: try to write each one as a metafunction, and thus
> render knowledge of it obsolete altogether.
>
> It's certainly one source. The best, I don't know - things like
> serialization and persistence are oft-mentioned examples
> of problems where reflection/injection is a big help, but they aren't
> necessarily well-represented in pattern books.
>

Add hashing and garbage collection to this list. Maybe RTTI too.

I'll make an observation and a rather bold claim:

Observation: All of these problems fall into the same class, what I've
been calling "structural algorithms". These are all characterized by four
main components:

- An underlying system or context that the algorithm operates on (e.g., an
output stream for serialization, GC roots, ...).
- A set of concrete algorithms that operate on built-in types.
- A generic algorithm that operates on the structure of user-defined types,
possibly with specializations and refinements for special cases and
optimization.
- An ability to customize the generic algorithm when it would do the wrong
thing.

Claim: This entire class of problems can be fully solved with only
templates, reflection, and splicing.

These aren't the only problems solved with those features, and these
features clearly don't solve all metaprogramming problems. It may also be
that these algorithms can benefit from more advanced features like
injection, stereotypes, metaclasses, or... whatever else we dream up. But
this is a good class of problems to solve.

Andrew