Re: Determining the registered DGM classes at runtime
On 08.04.2018 18:51, Cédric Champeau wrote: 2018-04-06 22:42 GMT+02:00 Jochen Theodorou>: ah sorry, I was not explaining right... I was going to suggest something similar to what you probably already have found, which is StaticTypeCheckingSupport.EXTENSION_METHOD_CACHE.getExtensionMethods(ClassLoader) but for some reason I do not understand the constant is protected and the type for it is a private static inner class... which means nobody can use this really. bummer. So maybe patch that and make it public? See GROOVY-8536 for this It is private because it was never meant for external consumption. It's much easier to evolve an API/internals if things are kept private. sure, but then why make EXTENSION_METHOD_CACHE protected? This is contradicting Look at the nightmare of people using internal APIs in Gradle and you'll understand what I mean: the more the API is open, the bigger the surface is, and the higher the risk to break consumers when you want to change an implementation detail is. So we _could_ make this API public, but then it means adding test coverage and making sure we stabilize the API, if it ever makes sense. for IDE plugins having an infrastructure like there absolutely makes sense. I can also see some joint compilation usages for this bye Jochen
Re: Determining the registered DGM classes at runtime
2018-04-06 22:42 GMT+02:00 Jochen Theodorou: > ah sorry, I was not explaining right... > > I was going to suggest something similar to what you probably already have > found, which is StaticTypeCheckingSupport.EXTE > NSION_METHOD_CACHE.getExtensionMethods(ClassLoader) > but for some reason I do not understand the constant is protected and the > type for it is a private static inner class... which means nobody can use > this really. bummer. So maybe patch that and make it public? See > GROOVY-8536 for this > > It is private because it was never meant for external consumption. It's much easier to evolve an API/internals if things are kept private. Look at the nightmare of people using internal APIs in Gradle and you'll understand what I mean: the more the API is open, the bigger the surface is, and the higher the risk to break consumers when you want to change an implementation detail is. So we _could_ make this API public, but then it means adding test coverage and making sure we stabilize the API, if it ever makes sense.
Re: Determining the registered DGM classes at runtime
ah sorry, I was not explaining right... I was going to suggest something similar to what you probably already have found, which is StaticTypeCheckingSupport.EXTENSION_METHOD_CACHE.getExtensionMethods(ClassLoader) but for some reason I do not understand the constant is protected and the type for it is a private static inner class... which means nobody can use this really. bummer. So maybe patch that and make it public? See GROOVY-8536 for this In theory you could go through MetaClassImpl, but I think that will a lot more than you want. bye Jochen On 06.04.2018 21:16, eric.mil...@thomsonreuters.com wrote: What API can I call to get a list of modules? I'm having trouble determining the actual entry point. -Original Message- From: Jochen Theodorou [mailto:blackd...@gmx.org] Sent: Friday, April 06, 2018 1:36 PM To: dev@groovy.apache.org Subject: Re: Determining the registered DGM classes at runtime On 06.04.2018 18:42, eric.mil...@thomsonreuters.com wrote: Is it possible to determine the available Category (aka DGM) extension classes at runtime? I have been relying on DefaultGroovyMethods.DGM_LIKE_CLASSES, but this has been getting reduced with each release due to modularization. And it was never really a good source to begin with. I tried looking through ExtensionModuleRegstry, but I couldn't make out a good entry point for asking for the DGM classes. you will have to build an index for this I think. You can ask for a list of modules and also for the available methods in each. Or you simulate the discovery mechanism and play it from there without instantiating any of the Modules bye Jochen
RE: Determining the registered DGM classes at runtime
What API can I call to get a list of modules? I'm having trouble determining the actual entry point. -Original Message- From: Jochen Theodorou [mailto:blackd...@gmx.org] Sent: Friday, April 06, 2018 1:36 PM To: dev@groovy.apache.org Subject: Re: Determining the registered DGM classes at runtime On 06.04.2018 18:42, eric.mil...@thomsonreuters.com wrote: > Is it possible to determine the available Category (aka DGM) extension > classes at runtime? I have been relying on > DefaultGroovyMethods.DGM_LIKE_CLASSES, but this has been getting > reduced with each release due to modularization. And it was never > really a good source to begin with. I tried looking through > ExtensionModuleRegstry, but I couldn't make out a good entry point for > asking for the DGM classes. you will have to build an index for this I think. You can ask for a list of modules and also for the available methods in each. Or you simulate the discovery mechanism and play it from there without instantiating any of the Modules bye Jochen
Re: Determining the registered DGM classes at runtime
On 06.04.2018 18:42, eric.mil...@thomsonreuters.com wrote: Is it possible to determine the available Category (aka DGM) extension classes at runtime? I have been relying on DefaultGroovyMethods.DGM_LIKE_CLASSES, but this has been getting reduced with each release due to modularization. And it was never really a good source to begin with. I tried looking through ExtensionModuleRegstry, but I couldn't make out a good entry point for asking for the DGM classes. you will have to build an index for this I think. You can ask for a list of modules and also for the available methods in each. Or you simulate the discovery mechanism and play it from there without instantiating any of the Modules bye Jochen
Determining the registered DGM classes at runtime
Is it possible to determine the available Category (aka DGM) extension classes at runtime? I have been relying on DefaultGroovyMethods.DGM_LIKE_CLASSES, but this has been getting reduced with each release due to modularization. And it was never really a good source to begin with. I tried looking through ExtensionModuleRegstry, but I couldn't make out a good entry point for asking for the DGM classes. I see STC using this stuff to ask if a given method name is a DGM. But this does not meet the needs of content assist, which must suggest all method names for a given prefix.