The proposed change makes Cayenne agnostic to the form of getters and setters. So no existing users are going to be affected, but those experimenting with custom class structures will no longer be constrained.
(FWIW, I'd like our built-in template setters to return "this" instead of "void", but that's a separate discussion). Andrus > On Feb 3, 2025, at 3:18 PM, John Huss <johnth...@gmail.com> wrote: > > I'm not opposed to this at all. But I want to mention that there are java > libraries in the larger ecosystem that depend on these "bean"-style methods > in order to function (out-of-the-box). Typically this would be > serialization libraries, like Jackson/JSON. But could be HTML templating > libraries too, or reporting libraries. So maybe be careful what you wish > for? > > > On Sun, Feb 2, 2025 at 9:51 AM Hugi Thordarson <h...@karlmenn.is> wrote: > >> Hi Andrus, >> >> Thanks for taking a look at this. The only part where I noticed method >> naming directly affecting my own work is #3, since I tend to do a lot of >> in-memory sorting and filtering of collections of Persistents based on >> their attributes/Properties. Although I also vaguely remember random errors >> popping up which may then have been due to #4. >> >> So definitely taking that lovely red pill! :) >> >> Cheers, >> - hugi >> >> >> >>> On 2 Feb 2025, at 15:00, Andrus Adamchik <aadamc...@gmail.com> wrote: >>> >>> Hi Hugi, >>> >>> I haven't looked at this code in a while, but the framework was designed >> to use Persistent interface methods (readPropertyDirectly(..), >> writePropertyDirectly(..) and so on) to access object state, not >> reflection. With PropertyUtils and BeanAccessor we veered of that course. >> Here are a few BeanAccessor scenarios I dug up: >>> >>> 1. Persistent.readNestedProperty(..) for non-persistent properties >>> 2. In-memory expression evaluation on POJOs >>> 3. In-memory expression evaluation on Persistent objects >>> 4. Reading "persistentState" property from a Persistent object >>> >>> Most apps hopefully don't care for #1 & #2. (those were cool features >> before Java streams. Now they are not very useful, and I would argue, out >> of scope for Cayenne. But they are not harmful either and can remain. #3 & >> #4 are just incorrect implementations and should be changed. We should not >> be using reflection where Persistent interface is present. >>> >>> I may be missing more cases, but you see where I am getting with this. >> After some cleanup, Cayenne would not care whether you call your getters >> "getXyz()" or "xyz()", and what you propose becomes purely a task of >> writing a custom template. And with 5.0 improvements, templates can be >> stored in your project and managed by the Modeler. So I suggest we focus on >> this cleanup. >>> >>> To quote The Matrix, when we are ready, we won't have to dodge bullets. >>> >>> Andrus >>> >>> >>>> On Feb 2, 2025, at 7:38 AM, Hugi Thordarson <h...@karlmenn.is> wrote: >>>> >>>> Hi all! >>>> >>>> With 5.0 under development, I’d like to re-awaken an old proposal. >>>> >>>> When Cayenne generates classes, you’ll by default get JavaBean style >> prefixes for attribute/relationship method names (“get” and “is”). I've >> never used those and really don't want class generation to affect my method >> names, so I use my own superclass template that does not include those >> prefixes and patch in my own “BeanAccessor” (which is used by Cayenne to >> invoke class methods) that assumes the prefixes are not present. >>>> >>>> Since I finally have time to do some Cayenne advocacy, I’m finding it >> feels hacky to instruct folks to drop in a patch if they don’t want the >> method name prefixes — so I’d like to propose that allowing classes to have >> non-prefixed method names be made an option in the Cayenne core. >>>> >>>> I’d submit a pull request, but I don’t think I’m the best to propose >> how to go about this. I change the behaviour myself by invoking >> PropertyUtils.installAccessorFactory() with my own implementation ( >> https://gist.github.com/hugithordarson/0367e4e9672df95559d331f072597662 ) >> (that has to be in the package it is, since it relies on package protected >> functionality from Cayenne) but I guess a more friendly way (if not a >> configuration option) would be to make the BeanAccessor injectable. >>>> >>>> I don't think I’ll propose adding non-prefixed templates in the core as >> well — adding one's own class generation template to a project feels much >> more “normal” than dropping in a “hack class” to make things work. But just >> having the functionality of NonPrefixedBeanAccessor available in core would >> be a definite improvement. >>>> >>>> Furthermore, Carthago delenda something something :D >>>> >>>> Cheers, >>>> - hugi >>> >> >>
