You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "will mason (JIRA)" <ji...@apache.org> on 2016/12/01 21:57:58 UTC

[jira] [Comment Edited] (GROOVY-4189) Removing a metaClass method

    [ https://issues.apache.org/jira/browse/GROOVY-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15713193#comment-15713193 ] 

will mason edited comment on GROOVY-4189 at 12/1/16 9:57 PM:
-------------------------------------------------------------

G'day, It looks as if this request is still open, which is good.  

I have two use-cases.  
# Firstly you want to remove a method
# Second you may need to replace / update a certain method 
#*  Not an override

The second case may not be at issue, however if you can't set the method dispatch to null, then I suspect that is the same problem.

I have one suggestion.  If there is a means provided to '_identify_' the method, get the signature, then one might have a possible mechanism to only remove specific method(s) (and/or propert(ies)) .

Something like the following....

{code:groovy:title=Bar.java|borderStyle=solid}
      candidates = Test.metaClass.getSignatures( "foo" ) 
        //  ==> collection of signatures for matches
      candidates.each { 
          if (....) {
             killList.add( it )
          }
      }
      Test.metaClass.remove( killList )
{code}

When you have the list of all possibilities -- The user/programmer can choose.  Other options become difficult because the language can err by deleting too many or not enough.

This way might mean some explicit administration by the programmer, however it also demonstrates that what they wish to do is not just a "straightforward remove" as it were.



was (Author: aplatypus):
G'day, It looks as if this request is still open, which is good.  

I have two use-cases.  
# Firstly you want to remove a method
# Second you may need to replace / update a certain method 
#*  Not an override

The second case may not be at issue, however if you can't set the method dispatch to null, then I suspect that is the same problem.

I have one suggestion.  If there is a means provided to '_identify_' the method, get the signature, then one might have a possible mechanism to only remove specific method(s) (and/or propert(ies)) .

Something like the following....

{code:groovy:title=Bar.java|borderStyle=solid}
      candidates = Test.metaClass.getSignatures( "foo" ) ==> collection of signatures for matches
      candidates.each { 
          if (....) {
             killList.add( it )
          }
      }
      Test.metaClass.remove( killList )
{code}

When you have the list of all possibilities -- The user/programmer can choose.  Other options become difficult because the language can err by deleting too many or not enough.

This way might mean some explicit administration by the programmer, however it also demonstrates that what they wish to do is not just a "straightforward remove" as it were.


> Removing a metaClass method
> ---------------------------
>
>                 Key: GROOVY-4189
>                 URL: https://issues.apache.org/jira/browse/GROOVY-4189
>             Project: Groovy
>          Issue Type: Improvement
>          Components: groovy-jdk
>    Affects Versions: 1.7.2
>            Reporter: Tim Yates
>            Priority: Minor
>             Fix For: 3.0
>
>
> Spotted a question on stackoverflow about removing a metaclass method
> The page here
> http://groovy.codehaus.org/JN3525-MetaClasses
> Says you should be able to do it by setting it to null, but we get this:
> {code}
> String.metaClass.foo = { "${delegate}foo" }
> assert 'kung'.foo() == 'kungfoo'
> String.metaClass.foo = null
> assert 'woo'.foo() == 'woofoo'
> {code}
> That last assert should fail (according to the docs), but it passes
> Is this a documentation issue?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)