You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Paul King (Jira)" <ji...@apache.org> on 2022/03/21 04:33:00 UTC
[jira] [Comment Edited] (GROOVY-9382) Inconsistent support for [Bb]oolean properties
[ https://issues.apache.org/jira/browse/GROOVY-9382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17030113#comment-17030113 ]
Paul King edited comment on GROOVY-9382 at 3/21/22, 4:32 AM:
-------------------------------------------------------------
There are some historical differences around {{boolean}} vs {{Boolean}} which I think stem back to the JavaBean Specification. The wording in the spec and examples in official language tutorials all only refer to special naming for primitive {{boolean}}:
{quote}
*8.3.2 Boolean properties*
In addition, for {{boolean}} properties, we allow a getter method to match the pattern:
{{public boolean is<PropertyName>();}}
This "is<PropertyName>" method may be provided instead of a "get<PropertyName>" method, or it may be provided in addition to a "get<PropertyName>" method.
{quote}
You could interpret that to also apply to {{Boolean}} but various early frameworks didn't and many then stuck to that convention. The current rules for dynamic Groovy were a compromise to make Groovy work with those early frameworks. From memory, but a long time back now, there were some serialization frameworks that wrote two copies of a property into the serialized form if we had a getX and isX Boolean for instance. The rules for static Groovy were perhaps eased off to reflect more recent frameworks.
I note these comments for historical context, not to dissuade moving to a more consistent state. Early versions of hibernate or serialisation frameworks could break if we change things but as long as we check recent frameworks we should be okay. We need to make sure we formalise our behavior in the documentation.
was (Author: paulk):
There are some historical differences around {{boolean}} vs {{Boolean}} which I think stem back to the JavaBean Specification. The wording in the spec and examples in official language tutorials all only refer to special naming for primitive {{boolean}}:
bq. *8.3.2 Boolean properties*
bq. In addition, for {{boolean}} properties, we allow a getter method to match the pattern:
bq. {{public boolean is<PropertyName>();}}
bq. This “is<PropertyName>” method may be provided instead of a “get<PropertyName>” method, or it may be provided in addition to a “get<PropertyName>” method.
You could interpret that to also apply to {{Boolean}} but various early frameworks didn't and many then stuck to that convention. The current rules for dynamic Groovy were a compromise to make Groovy work with those early frameworks. From memory, but a long time back now, there were some serialization frameworks that wrote two copies of a property into the serialized form if we had a getX and isX Boolean for instance. The rules for static Groovy were perhaps eased off to reflect more recent frameworks.
I note these comments for historical context, not to dissuade moving to a more consistent state. Early versions of hibernate or serialisation frameworks could break if we change things but as long as we check recent frameworks we should be okay. We need to make sure we formalise our behavior in the documentation.
> Inconsistent support for [Bb]oolean properties
> ----------------------------------------------
>
> Key: GROOVY-9382
> URL: https://issues.apache.org/jira/browse/GROOVY-9382
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.4.18, 2.5.9, 3.0.0-rc-3
> Reporter: Eric Milles
> Assignee: Eric Milles
> Priority: Major
> Fix For: 4.0.0-beta-1
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In addition to issues noted in GROOVY-5245 and GROOVY-6097, consider the following:
> {code:groovy}
> class Pogo {
> Boolean b = true
> }
> def pogo = new Pogo()
> println pogo.b // prints "true"
> println pogo.getB() // prints "true"
> println pogo.isB() // throws MissingPropertyException
> {code}
> If {{@TypeChecked}} is added, no STC error for {{pogo.isB()}}. If {{@CompileStatic}} is added, no STC error for {{pogo.isB()}} and exception changes to NoSuchMethodError.
> I'd prefer a Boolean property could be accessed using an "is" method. If the scenario is reversed (class with only {{Boolean isB()}} method), the property expression {{pogo.b}} is supported.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)