I think we need the current behavior for the almost-backward-compatible behavior that incompatibleImprovements 2.3.33 promises. (Although it's "incompatible", there's a promise that as far as it's 2.3.x, it only enables changes that are most likely won't break your application, hence when someone discovers that they need some of the improvements it brings, they can usually crank it up, and get all the other improvements too, instead of people having some unique permutation of "improvements" enabled.) So maybe ZeroArgumentNonVoidMethodPolicy.PROPERTY_ONLY should be called PROPERTY_UNLESS_BEAN_PROP_READ_METHOD (oh my...), and BOTH_PROPERTY_AND_METHOD should called PROPERTY_UNLESS_BEAN_PROP_READ_METHOD_AND_METHOD (even funnier name). And then later we can introduce other policies if needed, which are less backward compatible, but might be seen cleaner or more obvious.
On Sun, Mar 31, 2024 at 4:49 PM Simon Hartley <scrhart...@yahoo.co.uk.invalid> wrote: > > 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 -- Best regards, Daniel Dekany
