[
https://issues.apache.org/jira/browse/GROOVY-11516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895581#comment-17895581
]
Jochen Theodorou commented on GROOVY-11516:
-------------------------------------------
I do agree that $ is often used to specify something internal. But normally
then something else is supposed to be used instead. The issue sounds
like:{code:Java}
new Foo()."amountIn$" = 20
{code}should no longer be possible. But since you only modify getProperties(),
setting the then "hidden property" should still work. But how will you realize
the variant in which you do want to print out amountIn$ for @ToString with
allNames=true? There is no API for that.
Also for @ToString I would think about a functional variant.
{code:java}
@ToString(includeFields=true, includeNames=true, filterNames={name ->
!name.contains('$')})
{code}
Don't take it as a solution, just as food for thought. But the point I am
aiming for is that you want some kind of filtering not only in ToString, but
also for toJson and maybe many other situations... so maybe we should even go
as far as having some kind of {code:Java}
@Internal(name -> name.contains('$'){code}
Or to come back to "normally then something else is supposed to be used
instead":
{code:Java}@NameTransformer(name -> name.contains($')? null:name){code}
Allowing you to control the output...
This can then be used by getProperties(), toJson and toString, though then we
would also have to discuss if that forms a valid name for setting the property.
> Improve consistency of treatment for internal properties
> --------------------------------------------------------
>
> Key: GROOVY-11516
> URL: https://issues.apache.org/jira/browse/GROOVY-11516
> Project: Groovy
> Issue Type: Improvement
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
> Labels: breaking
>
> In numerous places, property names containing a "$" are deemed internal but
> not MetaClassImpl#getProperties. This means for instance that
> JsonOutput.toJson() currently outputs such internal properties.
> After this change, such properties would not normally be returned. No test
> fails after such a change indicating that this is an edge case we haven't
> covered previously.
> This would be a breaking change if anyone is really on the existing edge case
> behavior. If necessary, we could use a system property to re-enable the
> system behavior. We already have a system property
> "groovy.permissive.property.access". We could use
> "groovy.dollar.property.access" as well but I wasn't planning to add this
> unless we get feedback that some folks need it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
