StrangeNoises commented on pull request #1601: URL: https://github.com/apache/groovy/pull/1601#issuecomment-878195448
It looks like you'd need the `StaticTypesTransformation::visit` method to take after its subclass `StaticCompileTransformation::visit` and actually set the `WriterControllerFactory` on the ClassNode, as well as a flag to say that this class/method is `@TypeChecked` (as per the subclass setting one indicating it's `@CompileStatic`). Of course you don't have this at the moment because, once the actual type-checking is done, you want the code to be actually generated in the same dynamic fashion as normal. But that's why we don't have the `StaticTypesTypeChooser` here. 😀 The hypothetical `StaticTypeCheckedWriterController` probably wants to be a superclass of the current `StaticTypesWriterController` (which maybe ought to be called `StaticCompileWriterController`, these `StaticTypes*` methods actually pertaining to static compile confused me for a while) so that the latter can still defer upwards through the former, so you can still have classes with some methods `@CompileStatic` and some methods `@TypeChecked`. This `StaticTypeCheckedWriterController` wouldn't actually have much, just the `StaticTypesTypeChooser` and a `StaticTypeCheckedInvocationWriter`... which is where my varargs fix would actually go. And anything else we can think of where information known because we're in a `@TypeChecked` context actually wants to influence how code is generated. ... if only we could think of one other thing to make all this refactoring worthwhile... 😉 My issue, generalised, is that we'd want to cover situations when the type of an argument expression is significant even if the expression yields a null value. But the only other use-case I've so far come up with for that is matching to the correct overloaded method with a null argument, and that would still need a static invocation to resolve... unless we can send the list of argument *types* into the callsite... 😅 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
