Thanks John. But I’ve never used these prefixes and I think I can state with
some confidence that their importance is a little overrated. I think the only
library I’ve hit where this is a breaking problem with no “built-in” solution
is Cayenne :). In my usage, that is — definitely not claiming i
On Mon, Feb 3, 2025 at 3:27 PM Andrus Adamchik wrote:
> (FWIW, I'd like our built-in template setters to return "this" instead of
> "void", but that's a separate discussion).
>
I've made this change in custom templates before. I didn't test it
thoroughly (across a lot of libraries/frameworks), b
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
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
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
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
