blackdrag commented on PR #3086: URL: https://github.com/apache/groovy/pull/3086#issuecomment-6717151468
I am ok with this on the technical side, but not so much on the documentation side. If I have a MetaClass(X), and use it for class Y, then what kind of relation must they have. Surely we do not expect for X to be unrelated to Y or that Y is a super class (like for example Object) of X. What will really happen is that we may have MetaClass(X), but we work on an instance of Y. Every realized method invocation, field/property usage on that instance of Y through the MetaClass(X) that is actually performed on the class requires therefore the existence of that member. I see here potential problems with everything that is not public and from a different module, from a different classloader or from a different package. There is also the question how final members are handled. In general I think this can only work for methods properly (and properties as long as we use the accessors), with the condition that, to get the "original" behavior the method must forward the call to the real metho d. And when thinking about that I would actually extend the list of potentially problematic candidates to traits and interfaces with default methods. Of course I am making the case here much bigger than this issue intends. But the intend was a bugfix. What really happens in my eyes is restoring undocumented behavior that is largely undefined from the POV of a meta class. And the next change may break this again. Doing this properly makes this a new feature instead. -- 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]
