[code-reflection] RFR: More systematic binary op tests

[Paul Sandoz]

On Wed, 27 Mar 2024 17:03:42 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> What's your opinion on that?

If we lean into a test template approach with transformations then dealing with a template that is an instance method does not seem too difficult, just drop the first block parameter when transforming (any uses of that parameter means a test infrastructure bug) or pass the test instance argument.

The parameterized approach would i think be more familiar. If you like and have the time perhaps experiment with both appraoches? Perhaps there are valid uses for both kinds of approaches? Otherwise pick the one you think is better. I expect we might iterate on this area in subsequent PRs.

> 
> That thinking absolutely makes sense. Maybe it's enough to add some docs, but currently I would expect others to also be confused by the difference between `resultType()` and `invokableType().returnType()`. Otherwise, splitting up `Op` into more interfaces would probably make sense, but that's something that most likely requires more exploration of the overall concept I guess.

I wonder if, understandably, when initially encountering operation it is thought about in the more conventional sense e.g., add two numbers? But, it does not have to be. We can define an operation that *declares* a function, and its result type is certainly not the type of what the function returns when invoked, and it may not have a meaningful result (hence `void`, which i admit adds to the confusion, and perhaps `FunctionType` is more honest which would be equivalent to that returned by `invokableType`).

We do have a common interface that abstracts invokable operations, `Op.Invokable`, and that declares method `invokableType`.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/40#issuecomment-2025601475
PR Comment: https://git.openjdk.org/babylon/pull/40#issuecomment-2025621439