Just one more thing. On Tue, Jan 16, 2018 at 10:56 AM, Paul King <pa...@asert.com.au> wrote:
> 1) for me, if you have to explain a name better, then it is already a bad >> name. Intuitively suggesting the correct interpretation to another >> developer, without requiring him to thoroughly read through the >> documentation, is the art of picking good names (which imho Groovy overall >> does a good job at). >> With regards to @KnownImmutable, "someone (the compiler or the developer) >> knows" is even more confusing. If it is in fact irrelevant who knows it, >> why is there a "Known" in the name in the first place ? And why is >> therefore e.g. @IsImmutable not a better name (it could also carry a >> parameter which can be true or false, with false allowing a developer to >> express that a class is definitely not immutable (even if it might look >> that way on first glance; e.g. effectively blocking or issuing a warning in >> certain parallel execution scenarios)). >> > > We have since the introduction of @Immutable used the knownImmutable and > knownImmutableClasses annotation attributes and people seem to grok what > they mean. This is a very similar use case. I think it would be hard to > justify renaming @KnownImmutable without renaming the annotation attributes > as well. > I guess I missed one point. There are known immutable classes in Java, e.g. String, Integer, java.awt.Color, java.net.URI, java.util.UUID, etc. @Immutable processing knows about them but you can extend the list of classes with knownImmutableClasses=[...] and we are suggesting a further extension, you can annotate classes with @KnownImmutable. Cheers, Paul.
