At 2026-04-18 01:02:11, "Thiago Macieira" <thiago@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.