Re: Determining the registered DGM classes at runtime

2018-04-08 Thread Jochen Theodorou

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-08 Thread Cédric Champeau
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

2018-04-06 Thread 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


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

2018-04-06 Thread eric.milles
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

2018-04-06 Thread Jochen Theodorou

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

2018-04-06 Thread eric.milles
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.