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 >
