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 > > > >
