For me, adding hooks into visitBinaryExpression is the way to go – I think that is your option 3. The type-checker could be looking up the method name associated with the binary operator and then checking as a method call. It looks like all that is missing and getResultType indicates that all comparisons are boolean. The actual conversion from binary expression to method call expression happens later in BinaryExpressionTransformer.
Not sure if adding a method to the TypeCheckingExtension is better versus using beforeMethodCall, onMethodSelection and afterMethodCall. In order to override the equals to perform as you expected, did you need to drop into dynamic mode? Or were you able to get it to go, but the types did not check properly in some cases? ________________________________ From: Paul King <pa...@asert.com.au> Sent: Monday, April 8, 2024 10:21 PM To: dev@groovy.apache.org <dev@groovy.apache.org> Subject: [EXT] Re: Potential enhancement to type checking extensions External Email: Use caution with links and attachments. I also think option 4 is the right way to go. Option 3 has the benefit that both the operator and method call could be covered just by handling the method call (since the former is converted into the latter). Option 4 might require you to cover both cases in your type extension - but that might also be what is desired. Looking at Scala, it seems that they only apply Multiversal Equality when using the operator, not when using the equals method. Cheers, Paul. On Mon, Apr 8, 2024 at 11:28 PM Jochen Theodorou <blackd...@gmx.org> wrote: > > On 08.04.24 13:56, Paul King wrote: > [...] > > What I wanted to show is the same examples but using the '==' and '!=' > > operators, since that would be the typical Groovy style for this > > scenario. Unfortunately, using the type checking extension DSL doesn't > > currently work for binary operators. The swap from '==' to the > > 'equals' method call occurs well after type checking is finished. The > > same would apply to operators eventually falling back to 'compareTo'. > > the replacements may be even on ScriptBytecodeAdapter. > > > You can still make it work by not using the DSL and writing your own > > type checking extension, but that's significantly more work. > > > > Our options seem to be: > > (1) not trying to make this work > > (2) modify operators to method call expressions earlier (might remove > > some optimization steps) > > (3) tweak StaticTypeCheckingVisitor#visitBinaryExpression to support > > before/after method call hooks for known cases like equals/compareTo > > with a pretend method call > > (4) alter the TypeCheckingExtension interface with before/after binary > > expression calls. > > > [...] > > > > Does anyone have strong opinions on this before I start having a play > > and seeing what might work? In particular, a preference for option 3 > > or 4? > > Doing that only for special cases does not sound right to me. I would be > for option 4... is there anything speaking against that? > > bye Jochen >
