If I was trying to do something here's an idea or two (please don't feel any pressure to implement this, I'm just thinking out loud):
How properties are implemented is from two sources: beans and simple non-voids. When the logic of both is being applied, then it's not a surprise that there are some strange interactions. If I could enable them separately, then I could turn off bean properties on records and have it work as I hoped. Otherwise perhaps I would need to have a backwards compatibility mode which is only enabled when using the default values. Or perhaps a setting which said whether beans or simple non-voids take precedence. I'm more than happy with the status quo; a few rough edges aren't the end of the world. I very much appreciate the effort you've already put in and what's been done is a huge improvement. Thank you so much, Simon On Sunday, 31 March 2024 at 02:05:32 BST, Daniel Dekany <daniel.dek...@gmail.com> wrote: Yeah, it is confusing/complicated if somebody digs into it. So you have `boolean isAccessible()` in a record. Because it's in a record, it's a good question what the intent of the author was (plus, now that the Java language makers make a mess, people will start using the same pattern in all kind of classes, randomly mixed with old-style getters). Like maybe it looks as a Java Beans property read method only accidentally, and they want this property-like thing to be called "isAccessible". But I think the most likely, by far, is that the authors are just confused about what the convention now is. Also, Java's java.beans.Introspector tells us that that's what it is: a Java Beans property called "accessible". FreeMarker doesn't try to guess if from the name. Also, this happens to be the most backward compatible behavior too. The end result is as below. These will work: myRecord.accessible - boolean value, because it's a Java Beans property called "accessible" myRecord.isAccessible() - which returns boolean, because a such a public method exists in Java, and therefore people expect it to work like in Java. This doesn't work: myRecord.accessible() - because there's no such method in Java, so it would be quite absurd myRecord.isAccessible - is not a boolean value, but a method, because that's how it always was with JavaBean property read methods. And then, you say, maybe myRecord.isAccessible should also be a boolean? I don't know... It's more backward incompatibility risk for sure. Also, note that if something is related to JavaBean properties, the ZeroArgumentNonVoidMethodPolicy doesn't apply. We decided that it's a JavaBean property read method, and end of story. That the ZeroArgumentNonVoidMethodPolicy name doesn't convey the exact meaning is true. Not sure what a better name could be though, that's not comically long. On Sat, Mar 30, 2024 at 1:11 AM Simon Hartley <scrhart...@yahoo.co.uk.invalid> wrote: > > Similarly, for a record with a field (component) called isActive, > its property name is currently "active" and not "isActive". > Additionally, this exposed property is callable as a method even when the > setting is PROPERTY_ONLY, > due to it being considered a bean property and not a record property. > > Is this the compromise we're making and something we'll live with, > or should we add more complexity so that this doesn't always apply? > > > > On Friday, 29 March 2024 at 23:29:31 GMT, Simon Hartley > <scrhart...@yahoo.co.uk.invalid> wrote: > > > > I've worked out what my confusion was: > > I was setting it to METHOD_ONLY and then becoming confused that the bean get > method still worked as a property. > Of course, this setting only affects zero-argument non-void methods which > ALSO aren't bean getter methods. > > I think that means that if a class was using non-bean style and has a field > called isActive, > then if you create a method for it called isActive, then its property name is > "active", not "isActive" > (even when set to BOTH_PROPERTY_AND_METHOD or PROPERTY_ONLY). > i.e. It's not exposed as both "active" (from the bean property syntax) and > "isActive" (from the non-bean style). > > I hope that's right and all as intended! > > Cheers, > Simon -- Best regards, Daniel Dekany
