> On Feb 21, 2021, at 4:14 PM, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>
> 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.

Those sound great. Why not try writing one, using the new syntax?

I think more of us be following Roland’s example, trying to actually implement these things, and presenting the results to the list. It’s a bit strange to be considering syntax changes without seeing it in action in large, real-world test cases.

And as Roland found, trying to implement these real world cases often leads us to places the proposals have overlooked, thus identifying deeper issues.

And beyond that, exchanging code instead of words would be a good way to lower the temperature in here and keep things in focus.

But Roland can’t be the only one.

I think I’ve said my peace and presented a useful test case of my own so I’ll bow out here and leave space for others, thanks all,

Dave

>
>> 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.