Date: Sun, 21 Feb 2021 23:14:38 +0200
On Sun, 21 Feb 2021 at 22:54, David Rector <davrec_at_[hidden]> wrote:
> Well said. Some leisurely thoughts expanding on this:
>
> Note too that such a metafunction, properly implemented, would indeed make that design pattern /obsolete/ — all the user need do is #include the right header and they can type `a + b + …` to their heart’s content, blissfully ignorant of the meaning of a "Mediator" and an "Observer" and all the expertise and manual labor the previous generation needed to code such things.
>
> 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. :)
As a side note, some of us do this already, to the extent the language
limitations allow it. We had a particular policy in
multiple places I worked in, which was "never (try to) make your type
a Singleton, use ourcompany::Singleton<YourType>.
Also, please leave it up to the application programmer to decide how
many of YourTypes should exist in their program, and
please never make that decision for them." Various other oft-mentioned
patterns are feasible to implement with such
a common library type/wrapper, but reflection+injection opens quite
some doors towards that ability. Like Proxies
and Mediators and Template Methods and Bridges etc.
> 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.
> FWIW, this belief is why I spent a year awhile back pretty much just learning clang and implementing the most general possible alternative to Andrew’s, without much regard to syntax or cleanliness. The resulting ugly "glorified preprocessor"/string mixin approach is a standard by which I think Andrew’s or any other alternative must be measured, and I will never be okay with any alternative that is not as capable as it, no matter how many people I admire and respect line up on the other side.
>
> But I would still very much welcome *improvements* on it that don’t sacrifice its capabilities — it is definitely not without its problems; e.g. recall Richard’s line that "a good metaprogram is semantic" — if indeed the "semantic" approach could be accomplished without losing the capabilities of the "syntactic" metaprogramming approach, I agree it is a big improvement, and thus Andrew’s endeavor to develop such a semantic approach is certainly worthwhile, though incomplete at this point.
>
> The challenge Andrew et al will face, it seems to me, is that, to implement injection properly in things like Sum<T,U> and PreCalcdSum<T,U> and other still more complex examples, you really just need to be able to write multiple statements in "meta" space, complete with meta variable declarations, control flow statements, etc. — *in the midst of writing arbitrary code *in "non-meta" space — i.e. in the midst of writing expressions, or initializers, or base classes.
Well.. I do expect to be able to inject function definitions, but I do
expect to do that semantically, meaning that I inject
code fragments that have injections in them, as opposed to injecting strings.
> Well said. Some leisurely thoughts expanding on this:
>
> Note too that such a metafunction, properly implemented, would indeed make that design pattern /obsolete/ — all the user need do is #include the right header and they can type `a + b + …` to their heart’s content, blissfully ignorant of the meaning of a "Mediator" and an "Observer" and all the expertise and manual labor the previous generation needed to code such things.
>
> 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. :)
As a side note, some of us do this already, to the extent the language
limitations allow it. We had a particular policy in
multiple places I worked in, which was "never (try to) make your type
a Singleton, use ourcompany::Singleton<YourType>.
Also, please leave it up to the application programmer to decide how
many of YourTypes should exist in their program, and
please never make that decision for them." Various other oft-mentioned
patterns are feasible to implement with such
a common library type/wrapper, but reflection+injection opens quite
some doors towards that ability. Like Proxies
and Mediators and Template Methods and Bridges etc.
> 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.
> FWIW, this belief is why I spent a year awhile back pretty much just learning clang and implementing the most general possible alternative to Andrew’s, without much regard to syntax or cleanliness. The resulting ugly "glorified preprocessor"/string mixin approach is a standard by which I think Andrew’s or any other alternative must be measured, and I will never be okay with any alternative that is not as capable as it, no matter how many people I admire and respect line up on the other side.
>
> But I would still very much welcome *improvements* on it that don’t sacrifice its capabilities — it is definitely not without its problems; e.g. recall Richard’s line that "a good metaprogram is semantic" — if indeed the "semantic" approach could be accomplished without losing the capabilities of the "syntactic" metaprogramming approach, I agree it is a big improvement, and thus Andrew’s endeavor to develop such a semantic approach is certainly worthwhile, though incomplete at this point.
>
> The challenge Andrew et al will face, it seems to me, is that, to implement injection properly in things like Sum<T,U> and PreCalcdSum<T,U> and other still more complex examples, you really just need to be able to write multiple statements in "meta" space, complete with meta variable declarations, control flow statements, etc. — *in the midst of writing arbitrary code *in "non-meta" space — i.e. in the midst of writing expressions, or initializers, or base classes.
Well.. I do expect to be able to inject function definitions, but I do
expect to do that semantically, meaning that I inject
code fragments that have injections in them, as opposed to injecting strings.
Received on 2021-02-21 15:14:52