blackdrag commented on PR #3086: URL: https://github.com/apache/groovy/pull/3086#issuecomment-6532607554
I do not have a technical concern for this issue, but I do have a bit of a problem with the nature of the issue itself. First of all... why did [GROOVY-12046](https://issues.apache.org/jira/browse/GROOVY-12046) not solve the problem? The description sounds very similar. But I have a more general problem... a meta class is supposed to answer for the class it stands for. An example of a meta class that stands in for another class is DelegatingMetaClass. To use a metaclass that is intended to represent a single class to represent another class qualifies for me as hack. Which means it may work, but it is not intended too and will break. At least in my thinking I was never considering a MetaClassImpl to do such a thing. And that is also not tested here. But is the code special for ExpandoMetaClass? If that would be the case it would be used in the implementation, which it is not. Of course I see the principle. You have an mock instance that is a subclass of the class you really want to test. You want to give it a meta class, that acts like the meta class of the class you want to test, but it will have to live on the mock instance. And maybe you even want to put methods on that mock instance, that are not supposed to "pollute" the original. At the same time you cannot do that on the original for the same reason. I understand that part perfectly. I just think that neither MetaClassImpl, nor ExpandoMetaClass are designed for this. Also... what if the instance you want to mock has for example a DelegatingMetaClass? Or even a custom meta class? -- 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]
