wrong work with property names in newer 4's

[OCsite <oc...@ocs.cz>]

Hi there,

after upgrading to 4.11, our code stopped working. Eventually I've succeeded to isolate the problem — looks like it is not able to properly distinguish a property foo and a method isFoo anymore:

===
147 ocs /tmp> <q.groovy                                   
class Foo {
    int ndx
    def opened=[] as Set
    boolean isOpened() {
        ndx in opened
    }

    static void main(String[] args) {
      Foo f=new Foo()
      f.opened<<3
      for (int n=0;n<5;n++) {
        f.ndx=n
         println "OP "+f.isOpened()
      }
   }
}
148 ocs /tmp> /usr/local/groovy-4.0.0-alpha-1/bin/groovy q
OP false
OP false
OP false
OP true
OP false
149 ocs /tmp> /usr/local/groovy-4.0.11/bin/groovy q       
Caught: groovy.lang.MissingMethodException: No signature of method: java.lang.Boolean.leftShift() is applicable for argument types: (Integer) values: [3]
groovy.lang.MissingMethodException: No signature of method: java.lang.Boolean.leftShift() is applicable for argument types: (Integer) values: [3]
	at Foo.main(q.groovy:10)
150 ocs /tmp> 
===

Thanks,
OC

RE: [EXT] wrong work with property names in newer 4's

[MG <mg...@arscreat.com>]

Hi guys,

 1. We use Mathematica notation for boolean/Boolean
    properties/fields/variables in our code, which is to append "Q"
    ("Question Mark") to the the name
     1. e.g. visibleQ, restartQ, ...
     2. Advantages are imho:
         1. One does not have to use is.../has.../shall... for different
            names
         2. Maximum brevity...
         3. ...while boolean properties/etc are still easy to spot and
            cannot be confused with non-boolean-properties
 2. Maybe something to consider if one has to refactor anyway due to
    this breaking change, if one does not need Java Bean spec
    compatibility...

Cheers,
mg


On 23/04/2023 17:44, Milles, Eric (TR Technology) via dev wrote:
>
> It is described in GROOVY-9382, GROOVY-10133, GROOVY-10707, 
> GROOVY-10821 and possibly others.
>
> """
>
> This was an intentional change for Groovy 4. There was much discussion 
> and it was noted as a breaking change, but may not have been that 
> prominent in the release notes. There are a few edge cases like 
> isFirstChild() and getFirstChild() with different return types in W3C 
> DOM. Your example above illustrates this same case.
>
> Improving the consistency of boolean and Boolean properties in 
> relation to the Java Bean spec and "developer intuition" (sorry to 
> have to go there) were primary goals.
>
> """
>
> https://issues.apache.org/jira/browse/GROOVY-10821
>

RE: [EXT] wrong work with property names in newer 4's

["Milles, Eric (TR Technology) via dev" <de...@groovy.apache.org>]

It is described in GROOVY-9382, GROOVY-10133, GROOVY-10707, GROOVY-10821 and possibly others.

"""
This was an intentional change for Groovy 4. There was much discussion and it was noted as a breaking change, but may not have been that prominent in the release notes. There are a few edge cases like isFirstChild() and getFirstChild() with different return types in W3C DOM. Your example above illustrates this same case.

Improving the consistency of boolean and Boolean properties in relation to the Java Bean spec and "developer intuition" (sorry to have to go there) were primary goals.
"""

https://issues.apache.org/jira/browse/GROOVY-10821