title: Can Hana's mechanism for customizing behavior via tag-dispatching be seen as a form of adapter pattern?
body: <h2>tl;dr</h2>
  <p>Is the customization of <code>boost::hana::transform</code> for <code>std::vector</code> (via specializing <code>boost::hana::tranform_impl</code> for the tag <code>ext::std::vector</code>) a form of <em><strong>Adaptor pattern</strong></em> that wraps the STL's <code>std::transform</code> into Hana's interface function <code>boost::hana::transform</code>?</p>
  <h2>Why this question</h2>
  <p>I'm reading <a href="https://refactoring.guru/design-patterns/book" rel="nofollow noreferrer"><em>Dive into Design Patterns</em></a>, and I'm a bit bothered by the fact that this resource, just like any others I've been peeping into (including <a href="https://www.oreilly.com/library/view/head-first-design/0596007124/ch01.html" rel="nofollow noreferrer"><em>Head First - Design Patterns</em></a>), doesn't have a single page, probably not even a paragraph, that doesn't contain the words <em>inheritance</em>/<em>virtual</em>/<em>extend</em>/etc, just like inheritance is the only way to understand and use design patterns.</p>
  <p>In an attempt to get a less inheritance-biased understanding of what these infamous patterns are, I'm trying to look at them from other perspectives, by asking what they look like in functional programming languages like Haskell (e.g. <a href="https://stackoverflow.com/q/66393236/5825294">this question</a>), or, with the present question, if a use of such patters is present in libraries which make use of a lot of template meta-programming, such as <a href="http://boostorg.github.io/hana/" rel="nofollow noreferrer">Boost.Hana</a>.</p>
  <h2>The question</h2>
  <p>If you look at <a href="https://github.com/boostorg/hana/blob/master/include/boost/hana/ext/std/vector.hpp" rel="nofollow noreferrer"><code>/usr/include/boost/hana/ext/std/vector.hpp</code></a>, there's some (commented) code for making <code>std::vector</code> a functor in the way that Hana defines it, i.e. by specializing the <code>transform_impl</code> template for <code>std::vector</code> (well, actually for the tag <code>ext::std::vector</code> which is associated to any <code>std::vector&lt;T&gt;</code>).</p>
  <p>The specialization obviously resorts to <code>std::transform</code> (and some template tricks/<code>enable_if</code>) to get the job done.</p>
  <p>The net effect, however, is that if I uncomment that code, then I'm able to use <code>boost::hana::transform</code> on <code>std::vector</code>, which I couldn't do without uncommenting that code.</p>
  <p>On the other hand, <code>std::vector</code> is conceptually a functor whether or not I have <code>boost::hana::transform</code> at my disposal. Indeed, <code>std::transform</code> exists in the STL, and the &quot;only&quot; drawback is that it's not usable in a functional way because it's iterator-based.</p>
  <p>Therefore, it looks to me that customizing <code>boost::hana::transform</code> for <code>std::vector</code> (via specializing <code>boost::hana::tranform_impl</code> for the tag <code>ext::std::vector</code>) is a bit like adapting the STL interface to functors, <code>std::transform</code>, to Hana's interface, <code>boost::hana::transform</code>.</p>
  <p>Is this a valid interpretation?</p>
  <h2>The code</h2>
  <p><a href="https://godbolt.org/z/osqeKv" rel="nofollow noreferrer">Here</a> is a use-case and solution inspired to the <a href="https://refactoring.guru/design-patterns/book" rel="nofollow noreferrer">linked open source book</a>.</p>
  <p><a href="https://godbolt.org/z/ejfYEf" rel="nofollow noreferrer">Here</a> is the same use-case where I've used (hopefully correctly) the Hana approach to solve it. Since it solves the same problem, I'm tempted to self-answer that it is indeed a case of Adaptor pattern.</p>