------=_Part_331_2134474348.1423888784935
Content-Type: multipart/alternative;
 boundary="----=_Part_332_396043701.1423888784935"

------=_Part_332_396043701.1423888784935
Content-Type: text/plain; charset=UTF-8

Yes, multimethods have been done again and again.

I'm not sure if such a container exists, and I'm not claiming originality
here, either.

I don't care for the lack of control available at runtime with static
multimethods. I prefer to have explicit control over where and how pattern
matching of this nature is to occur, and be able to isolate groups of these
operations based on constructs that emerge only at runtime (e.g. available
OpenGL extensions based on what the driver supports for a given display,
supporting multiple different display adapters, etc...). There are, of
course, hundreds of different ways to model something like that, I just
found this pattern is the easiest to work with in that regard.

I've started an almost-skeleton implementation here:
https://github.com/warp-10/caster

Opinions and random, but related wisdom are welcome, as the idea is still
very rough.

Why a container? Above all other architectural smells, I despise hidden
library allocations. Static multimethods would require a singleon-like
allocator interface to control where new dispatch table entries are
allocated. A container alleviates this issue by keeping allocations in one
or a few well-defined places, and also eliminates the need for new syntax
(unrelated callables can be used with the same dispatch mechanism without
the need for consistency checking outside the container interface).

That said, if static multimethods were incorporated into the language, this
library would still benefit from the required ABI changes.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_332_396043701.1423888784935
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, multimethods have been done again and again.<br><br>I=
'm not sure if such a container exists, and I'm not claiming originality he=
re, either.<br><br>I don't care for the lack of control available at runtim=
e with static multimethods. I prefer to have explicit control over where an=
d how pattern matching of this nature is to occur, and be able to isolate g=
roups of these operations based on constructs that emerge only at runtime (=
e.g. available OpenGL extensions based on what the driver supports for a gi=
ven display, supporting multiple different display adapters, etc...). There=
 are, of course, hundreds of different ways to model something like that, I=
 just found this pattern is the easiest to work with in that regard.<br><br=
>I've started an almost-skeleton implementation here:<a href=3D"https://git=
hub.com/warp-10/caster"> https://github.com/warp-10/caster</a><br><br>Opini=
ons and random, but related wisdom are welcome, as the idea is still very r=
ough.<br><br>Why a container? Above all other architectural smells, I despi=
se hidden library allocations. Static multimethods would require a singleon=
-like allocator interface to control where new dispatch table entries are a=
llocated. A container alleviates this issue by keeping allocations in one o=
r a few well-defined places, and also eliminates the need for new syntax (u=
nrelated callables can be used with the same dispatch mechanism without the=
 need for consistency checking outside the container interface).<br><br>Tha=
t said, if static multimethods were incorporated into the language, this li=
brary would still benefit from the required ABI changes.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_332_396043701.1423888784935--
------=_Part_331_2134474348.1423888784935--

.

------=_Part_80_91351595.1424347796649
Content-Type: multipart/alternative;
 boundary="----=_Part_81_2042933207.1424347796649"

------=_Part_81_2042933207.1424347796649
Content-Type: text/plain; charset=UTF-8

*SHORT VERSION:*

A type map that efficiently applies dynamic_cast to an input argument over
a dynamic set of types.

Like "unordered_map<type_index, function<...>>", except that it handles
lookup automatically and casts the input argument list to the best-fitting
callable in the collection.

Great for:

   - Extensible message passing, where the central "message" server need
   not expose any additional registration mechanism (no need for parallel
   meta-typing).
   - Open-ended type mapping: Map things like an 'image<2, rgba>' to a
   handler that directs an implementation pointer to a 'GLImage<2, GL_RGBA>'
   allocation.
   - Open-ended AST visitors: Extend an AST visitor at runtime to accept
   new node types without altering the visitor's definition.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_81_2042933207.1424347796649
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><b>SHORT VERSION:</b><br><br>A type map that efficiently a=
pplies dynamic_cast to an input argument over a dynamic set of types.<br><b=
r>Like "unordered_map&lt;type_index, function&lt;...&gt;&gt;", except that =
it handles lookup automatically and casts the input argument list to the be=
st-fitting callable in the collection.<br><br>Great for:<br><ul><li>Extensi=
ble message passing, where the central "message" server need not expose any=
 additional registration mechanism (no need for parallel meta-typing).<br><=
/li><li>Open-ended type mapping: Map things like an 'image&lt;2, rgba&gt;' =
to a handler that directs an implementation pointer to a 'GLImage&lt;2, GL_=
RGBA&gt;' allocation.</li><li>Open-ended AST visitors: Extend an AST visito=
r at runtime to accept new node types without altering the visitor's defini=
tion.<br></li></ul></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_81_2042933207.1424347796649--
------=_Part_80_91351595.1424347796649--

.