At 2026-04-18 01:02:11, "Thiago Macieira" <thiago_at_macieira.org> wrote:
>On Friday, 17 April 2026 03:43:00 Pacific Daylight Time Zhao YunShan wrote:
>> > - it is a static facility, many would prefer runtime configuration
>>
>> That's another subjective assertion. Being able to implement both static and
>> runtime features is progress. Use whichever you prefer.
>
>This was direct feedback consequence of how you described the feature syntax:
>there was no way to intercept at runtime, if the compiler didn't see the

>declaration.
I think I may have caused some confusion. What I meant was that both compile-time and link-time approaches should be supported.
My bad ¡ª I misread and mistyped, which gave you the wrong idea.
I wasn't talking about runtime, since the hooking strategy for runtime is a different thing altogether.

My point is that we should support both, rather than dropping one just because some people prefer the other.



>This is why you must write the paper. It's not clear how it's going to work.
>You may have thought of things that you didn't express well in the email and
>thus the rest of us are only seeing a limited subset of the capability.
>
>> Reflection is less efficient than Interceptors. By the way, we are
>> discussing Interceptors, so why did you bring up Reflection? It feels like
>> you're not really familiar with either of them.
>Why are they less efficient? Reflection happens entirely at compile time, so it's
>as efficient as any compiled code can be, including inlining. Interception can't
>catch inlined calls, because they have been inlined.


So, I'd like to ask for your expertise: how can reflection be used to implement interceptors that share the same function name and maintain a consistent calling interface, while achieving identical efficiency? How is this optimized? Could you provide an example?


>The reason Sebastian brought this up is that one typical case of
>"interception" is to create mock classes for testing, so one can verify that
>the right functions are called, the expected arguments are passed,
>preconditions and postcondition are met, etc. Having the ability to reflect an
>existing class and automatically create a mock would be extremely useful.


That's a design pattern issue. Also, judging by your description, it sounds like you're mocking the wrong thing.



>And yet this is not always possible to do, if one can't replace the class that
>is being called, buried deep inside layers of code. Intercepting the class at
>runtime would be useful.

My bad. For runtime hooks, you might want to refer to Detours -- it's considered a classic implementation in the field.

>--
>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.