Re: Allowing property getters without a "get" prefix on DataObjects

[Nikita Timofeev]

Thanks for PR, I think I'll have some time in a few days to merge it.
At first glance it seems ok.

On Sat, Apr 6, 2019 at 2:58 PM Hugi Thordarson  wrote:
>
> Thanks Nikita, we are finally well. And yes, I'd agree that the past flu 
> season kind of deserves an R-rated movie :).
>
> I finally submitted a PR with those slight modifications to BeanAccessor to 
> allow for easier subclassing. If you don't see anything wrong with it it 
> would be awesome if it reaches 4.1. I've been using this in production for 
> quite some time without any problems.
>
> https://github.com/apache/cayenne/pull/371 
> 
>
> Cheers,
> - hugi
>
>
>
> > Hi Hugi,
> >
> > "Flu season in Iceland" sounds like a scary movie :) Hope you are well!
> >
> > I've merged my pull request, so you can do yours. I don't see any
> > problems with adding some flexibility to BeanAccessor while keeping it
> > compatible.
> > And thanks for sharing your use case.
> >
> > On Wed, Feb 6, 2019 at 7:15 PM Hugi Thordarson  wrote:
> >>
> >> Hi Nikita!
> >> Sorry for the late reply. Flu season in Iceland, basically just happy to 
> >> be alive :).
> >>
> >> I'm working with Maik on this and just tried out your solution. It works 
> >> perfectly, so thanks!
> >>
> >> One point though: We would of course prefer to maintain as much of the 
> >> behaviour already present in BeanAccessor, but it's proving a bit 
> >> problematic to implement our own BeanAccessor this way, since the current 
> >> one uses a bit of protected/friendly logic from 
> >> org.apache.cayenne.reflect. This can be worked around by putting our own 
> >> BeanAccessor implementation in a package with that name (or duplicating 
> >> the required logic), but obviously, that's a bit … messy.
> >>
> >> I propose that BeanAccessor gets a new constructor which accepts 
> >> isGetterName, getGetterName and setterName as parameters, that the current 
> >> constructor can invoke with the current values. That way, our new 
> >> non-prefixed BeanAccessor implementation could just subclass BeanAccessor 
> >> and wouldn't have to touch any logic related to reading or setting 
> >> property values, it would only pass in our preferred property name 
> >> structure.
> >>
> >> At least that's one idea. If you agree with this, I'd be more than happy 
> >> to submit a PR with that modification once your PR has been merged.
> >>
> >> Cheers, and thanks again,
> >> - hugi
> >>
> >>
> >>
> >>> On 4 Feb 2019, at 13:12, Nikita Timofeev  
> >>> wrote:
> >>>
> >>> Hi Maik.
> >>>
> >>> As I'm the one researched this, let me answer :) I failed to make
> >>> BeanAccessor pluggable last time because I realized that it's deep
> >>> inside code not managed by Cayenne DI.
> >>> But looking again at it I wonder will this straightforward solution
> >>> [1] solve your problems?
> >>> And I'm really interested what is your use case? Do you perform lots
> >>> of in-memory filtering and/or calculations using Cayenne Expressions?
> >>>
> >>> [1] 
> >>> https://github.com/apache/cayenne/pull/363/files?utf8=✓=unified#diff-4f928c7d2ac0e22cabde0c9732de774fR214
> >>>
> >>> On Thu, Jan 31, 2019 at 7:22 PM Maik Musall  wrote:
> 
>  Hi Andrus,
> 
>  did you have a chance to look at this yet? The reason I ask is that our 
>  application hit the memory limit this week again (-Xmx at 96 GB), and 
>  according to some profiling, almost half of that is used up by HashMap 
>  nodes. So we're really eager to upgrade to Cayenne 4.1 to be able to use 
>  field-based DataObjects, but this is preventing us from going ahead.
> 
>  Thanks
>  Maik
> 
> 
> 
> > Am 25.09.2018 um 16:23 schrieb Andrus Adamchik :
> >
> >> "Should Cayenne by default work without prefixed accessors".
> >
> > My answer to this : "By default, no. As a fallback or a custom 
> > strategy, possibly."
> >
> > I actually agree about Java beans. They are almost irrelevant now. And 
> > I wish Java gets "data classes" and some transparent form of 
> > "properties".
> >
> > As things stand now though, there's no common established alternative 
> > based on a naming convention that we can safely hardcode without 
> > causing grief for someone because they didn't expect that their method 
> > would be called when evaluating expressions. Hence my preference for a 
> > DI fix.
> >
> > So how about this... Unless someone else steps in by then, let me 
> > brainstorm it with Nikita a couple of weeks from now and see if we can 
> > do a DI solution. It is not nearly as involved as it appears.
> >
> > Andrus
> >
> >
> >> On Sep 25, 2018, at 9:59 AM, Hugi Thordarson  wrote:
> >>
> >> Hi Andrus and thanks for the reply,
> >>
> >> allowing replacement of the entire reflection strategy is certainly 
> >> nice and would allow me to make the customizations I need.
> >>
> >> 

Re: Allowing property getters without a "get" prefix on DataObjects

[Hugi Thordarson]

Thanks Nikita, we are finally well. And yes, I'd agree that the past flu season 
kind of deserves an R-rated movie :).

I finally submitted a PR with those slight modifications to BeanAccessor to 
allow for easier subclassing. If you don't see anything wrong with it it would 
be awesome if it reaches 4.1. I've been using this in production for quite some 
time without any problems.

https://github.com/apache/cayenne/pull/371 


Cheers,
- hugi



> Hi Hugi,
> 
> "Flu season in Iceland" sounds like a scary movie :) Hope you are well!
> 
> I've merged my pull request, so you can do yours. I don't see any
> problems with adding some flexibility to BeanAccessor while keeping it
> compatible.
> And thanks for sharing your use case.
> 
> On Wed, Feb 6, 2019 at 7:15 PM Hugi Thordarson  wrote:
>> 
>> Hi Nikita!
>> Sorry for the late reply. Flu season in Iceland, basically just happy to be 
>> alive :).
>> 
>> I'm working with Maik on this and just tried out your solution. It works 
>> perfectly, so thanks!
>> 
>> One point though: We would of course prefer to maintain as much of the 
>> behaviour already present in BeanAccessor, but it's proving a bit 
>> problematic to implement our own BeanAccessor this way, since the current 
>> one uses a bit of protected/friendly logic from org.apache.cayenne.reflect. 
>> This can be worked around by putting our own BeanAccessor implementation in 
>> a package with that name (or duplicating the required logic), but obviously, 
>> that's a bit … messy.
>> 
>> I propose that BeanAccessor gets a new constructor which accepts 
>> isGetterName, getGetterName and setterName as parameters, that the current 
>> constructor can invoke with the current values. That way, our new 
>> non-prefixed BeanAccessor implementation could just subclass BeanAccessor 
>> and wouldn't have to touch any logic related to reading or setting property 
>> values, it would only pass in our preferred property name structure.
>> 
>> At least that's one idea. If you agree with this, I'd be more than happy to 
>> submit a PR with that modification once your PR has been merged.
>> 
>> Cheers, and thanks again,
>> - hugi
>> 
>> 
>> 
>>> On 4 Feb 2019, at 13:12, Nikita Timofeev  wrote:
>>> 
>>> Hi Maik.
>>> 
>>> As I'm the one researched this, let me answer :) I failed to make
>>> BeanAccessor pluggable last time because I realized that it's deep
>>> inside code not managed by Cayenne DI.
>>> But looking again at it I wonder will this straightforward solution
>>> [1] solve your problems?
>>> And I'm really interested what is your use case? Do you perform lots
>>> of in-memory filtering and/or calculations using Cayenne Expressions?
>>> 
>>> [1] 
>>> https://github.com/apache/cayenne/pull/363/files?utf8=✓=unified#diff-4f928c7d2ac0e22cabde0c9732de774fR214
>>> 
>>> On Thu, Jan 31, 2019 at 7:22 PM Maik Musall  wrote:
 
 Hi Andrus,
 
 did you have a chance to look at this yet? The reason I ask is that our 
 application hit the memory limit this week again (-Xmx at 96 GB), and 
 according to some profiling, almost half of that is used up by HashMap 
 nodes. So we're really eager to upgrade to Cayenne 4.1 to be able to use 
 field-based DataObjects, but this is preventing us from going ahead.
 
 Thanks
 Maik
 
 
 
> Am 25.09.2018 um 16:23 schrieb Andrus Adamchik :
> 
>> "Should Cayenne by default work without prefixed accessors".
> 
> My answer to this : "By default, no. As a fallback or a custom strategy, 
> possibly."
> 
> I actually agree about Java beans. They are almost irrelevant now. And I 
> wish Java gets "data classes" and some transparent form of "properties".
> 
> As things stand now though, there's no common established alternative 
> based on a naming convention that we can safely hardcode without causing 
> grief for someone because they didn't expect that their method would be 
> called when evaluating expressions. Hence my preference for a DI fix.
> 
> So how about this... Unless someone else steps in by then, let me 
> brainstorm it with Nikita a couple of weeks from now and see if we can do 
> a DI solution. It is not nearly as involved as it appears.
> 
> Andrus
> 
> 
>> On Sep 25, 2018, at 9:59 AM, Hugi Thordarson  wrote:
>> 
>> Hi Andrus and thanks for the reply,
>> 
>> allowing replacement of the entire reflection strategy is certainly nice 
>> and would allow me to make the customizations I need.
>> 
>> However, if it's OK with you, rather than discuss implementation 
>> details, I'd like to take two steps back and revert to the more 
>> philosophical design question of:
>> 
>> "Should Cayenne by default work without prefixed accessors".
>> 
>> What is there to be lost or gained from keeping or abandoning the 
>> prefix-requirement?
>> 
>> I 

Re: Allowing property getters without a "get" prefix on DataObjects

[Nikita Timofeev]

Hi Hugi,

"Flu season in Iceland" sounds like a scary movie :) Hope you are well!

I've merged my pull request, so you can do yours. I don't see any
problems with adding some flexibility to BeanAccessor while keeping it
compatible.
And thanks for sharing your use case.

On Wed, Feb 6, 2019 at 7:15 PM Hugi Thordarson  wrote:
>
> Hi Nikita!
> Sorry for the late reply. Flu season in Iceland, basically just happy to be 
> alive :).
>
> I'm working with Maik on this and just tried out your solution. It works 
> perfectly, so thanks!
>
> One point though: We would of course prefer to maintain as much of the 
> behaviour already present in BeanAccessor, but it's proving a bit problematic 
> to implement our own BeanAccessor this way, since the current one uses a bit 
> of protected/friendly logic from org.apache.cayenne.reflect. This can be 
> worked around by putting our own BeanAccessor implementation in a package 
> with that name (or duplicating the required logic), but obviously, that's a 
> bit … messy.
>
> I propose that BeanAccessor gets a new constructor which accepts 
> isGetterName, getGetterName and setterName as parameters, that the current 
> constructor can invoke with the current values. That way, our new 
> non-prefixed BeanAccessor implementation could just subclass BeanAccessor and 
> wouldn't have to touch any logic related to reading or setting property 
> values, it would only pass in our preferred property name structure.
>
> At least that's one idea. If you agree with this, I'd be more than happy to 
> submit a PR with that modification once your PR has been merged.
>
> Cheers, and thanks again,
> - hugi
>
>
>
> > On 4 Feb 2019, at 13:12, Nikita Timofeev  wrote:
> >
> > Hi Maik.
> >
> > As I'm the one researched this, let me answer :) I failed to make
> > BeanAccessor pluggable last time because I realized that it's deep
> > inside code not managed by Cayenne DI.
> > But looking again at it I wonder will this straightforward solution
> > [1] solve your problems?
> > And I'm really interested what is your use case? Do you perform lots
> > of in-memory filtering and/or calculations using Cayenne Expressions?
> >
> > [1] 
> > https://github.com/apache/cayenne/pull/363/files?utf8=✓=unified#diff-4f928c7d2ac0e22cabde0c9732de774fR214
> >
> > On Thu, Jan 31, 2019 at 7:22 PM Maik Musall  wrote:
> >>
> >> Hi Andrus,
> >>
> >> did you have a chance to look at this yet? The reason I ask is that our 
> >> application hit the memory limit this week again (-Xmx at 96 GB), and 
> >> according to some profiling, almost half of that is used up by HashMap 
> >> nodes. So we're really eager to upgrade to Cayenne 4.1 to be able to use 
> >> field-based DataObjects, but this is preventing us from going ahead.
> >>
> >> Thanks
> >> Maik
> >>
> >>
> >>
> >>> Am 25.09.2018 um 16:23 schrieb Andrus Adamchik :
> >>>
>  "Should Cayenne by default work without prefixed accessors".
> >>>
> >>> My answer to this : "By default, no. As a fallback or a custom strategy, 
> >>> possibly."
> >>>
> >>> I actually agree about Java beans. They are almost irrelevant now. And I 
> >>> wish Java gets "data classes" and some transparent form of "properties".
> >>>
> >>> As things stand now though, there's no common established alternative 
> >>> based on a naming convention that we can safely hardcode without causing 
> >>> grief for someone because they didn't expect that their method would be 
> >>> called when evaluating expressions. Hence my preference for a DI fix.
> >>>
> >>> So how about this... Unless someone else steps in by then, let me 
> >>> brainstorm it with Nikita a couple of weeks from now and see if we can do 
> >>> a DI solution. It is not nearly as involved as it appears.
> >>>
> >>> Andrus
> >>>
> >>>
>  On Sep 25, 2018, at 9:59 AM, Hugi Thordarson  wrote:
> 
>  Hi Andrus and thanks for the reply,
> 
>  allowing replacement of the entire reflection strategy is certainly nice 
>  and would allow me to make the customizations I need.
> 
>  However, if it's OK with you, rather than discuss implementation 
>  details, I'd like to take two steps back and revert to the more 
>  philosophical design question of:
> 
>  "Should Cayenne by default work without prefixed accessors".
> 
>  What is there to be lost or gained from keeping or abandoning the 
>  prefix-requirement?
> 
>  I believe I can safely assert that Cayenne works fine without accessor 
>  prefixes, since I've used it that way on dozens of projects, so it looks 
>  like a somewhat arbitrary limitation. It's only with the introduction of 
>  field based DOs that we get a problem in a very isolated part of the 
>  framework.
> 
>  It seems to me that the java ecosystem is moving towards more modern API 
>  design—we've even got the architect of the Java language calling the 
>  bean-style "at best a questionable -- and certainly overused -- API 
>  

Re: Allowing property getters without a "get" prefix on DataObjects

[Hugi Thordarson]

Sorry, I neglected to answer your question about the use case.

Yes, we do quite a bit of work using both in-memory sorting using Ordering and 
filtering by Expression. Property.getFrom(...) is also very valuable when 
constructing dynamic UIs.

Although these things can certainly be performed using different means, being 
able to use the same object structures to perform both DB work and in-memory 
work is extremely useful, especially when it comes to complex object graphs 
with deep queries (long object paths).

Cheers,
- hugi


> On 4 Feb 2019, at 13:12, Nikita Timofeev  wrote:
> 
> Hi Maik.
> 
> As I'm the one researched this, let me answer :) I failed to make
> BeanAccessor pluggable last time because I realized that it's deep
> inside code not managed by Cayenne DI.
> But looking again at it I wonder will this straightforward solution
> [1] solve your problems?
> And I'm really interested what is your use case? Do you perform lots
> of in-memory filtering and/or calculations using Cayenne Expressions?
> 
> [1] 
> https://github.com/apache/cayenne/pull/363/files?utf8=✓=unified#diff-4f928c7d2ac0e22cabde0c9732de774fR214
> 
> On Thu, Jan 31, 2019 at 7:22 PM Maik Musall  wrote:
>> 
>> Hi Andrus,
>> 
>> did you have a chance to look at this yet? The reason I ask is that our 
>> application hit the memory limit this week again (-Xmx at 96 GB), and 
>> according to some profiling, almost half of that is used up by HashMap 
>> nodes. So we're really eager to upgrade to Cayenne 4.1 to be able to use 
>> field-based DataObjects, but this is preventing us from going ahead.
>> 
>> Thanks
>> Maik
>> 
>> 
>> 
>>> Am 25.09.2018 um 16:23 schrieb Andrus Adamchik :
>>> 
 "Should Cayenne by default work without prefixed accessors".
>>> 
>>> My answer to this : "By default, no. As a fallback or a custom strategy, 
>>> possibly."
>>> 
>>> I actually agree about Java beans. They are almost irrelevant now. And I 
>>> wish Java gets "data classes" and some transparent form of "properties".
>>> 
>>> As things stand now though, there's no common established alternative based 
>>> on a naming convention that we can safely hardcode without causing grief 
>>> for someone because they didn't expect that their method would be called 
>>> when evaluating expressions. Hence my preference for a DI fix.
>>> 
>>> So how about this... Unless someone else steps in by then, let me 
>>> brainstorm it with Nikita a couple of weeks from now and see if we can do a 
>>> DI solution. It is not nearly as involved as it appears.
>>> 
>>> Andrus
>>> 
>>> 
 On Sep 25, 2018, at 9:59 AM, Hugi Thordarson  wrote:
 
 Hi Andrus and thanks for the reply,
 
 allowing replacement of the entire reflection strategy is certainly nice 
 and would allow me to make the customizations I need.
 
 However, if it's OK with you, rather than discuss implementation details, 
 I'd like to take two steps back and revert to the more philosophical 
 design question of:
 
 "Should Cayenne by default work without prefixed accessors".
 
 What is there to be lost or gained from keeping or abandoning the 
 prefix-requirement?
 
 I believe I can safely assert that Cayenne works fine without accessor 
 prefixes, since I've used it that way on dozens of projects, so it looks 
 like a somewhat arbitrary limitation. It's only with the introduction of 
 field based DOs that we get a problem in a very isolated part of the 
 framework.
 
 It seems to me that the java ecosystem is moving towards more modern API 
 design—we've even got the architect of the Java language calling the 
 bean-style "at best a questionable -- and certainly overused -- API naming 
 convention" [http://cr.openjdk.java.net/~briangoetz/amber/datum.html 
 ] (pardon the 
 appeal to authority, but considering where it comes from, it's probably a 
 good barometer for where java language and API design is headed).
 
 I'd say that the framework would be well served and future-proofed by 
 dropping the requirement for hard-coded accessor prefixes as a baked in 
 requirement.
 
 Cheers,
 - hugi
 
 
 
> On 25 Sep 2018, at 11:15, Andrus Adamchik  wrote:
> 
> Hi Hugi,
> 
> My vote would be to do it right. There is a positive side effect that the 
> entire reflection strategy suddenly becomes customizable.
> 
> Andrus
> 
> 
>> On Sep 25, 2018, at 7:11 AM, Hugi Thordarson  wrote:
>> 
>> Hi Andrus, and y'all.
>> 
>> I've been looking into this and it seems like a rather large change to 
>> allow something relatively simple (allowing DataObjects to have accessor 
>> methods that don't start with a "get"-prefix).
>> 
>> Would people be diametrically opposed to just changing BeanAccessor so 
>> that it seeks for a non-prefixed method if a 

Re: Allowing property getters without a "get" prefix on DataObjects

[Hugi Thordarson]

Hi Nikita!
Sorry for the late reply. Flu season in Iceland, basically just happy to be 
alive :).

I'm working with Maik on this and just tried out your solution. It works 
perfectly, so thanks!

One point though: We would of course prefer to maintain as much of the 
behaviour already present in BeanAccessor, but it's proving a bit problematic 
to implement our own BeanAccessor this way, since the current one uses a bit of 
protected/friendly logic from org.apache.cayenne.reflect. This can be worked 
around by putting our own BeanAccessor implementation in a package with that 
name (or duplicating the required logic), but obviously, that's a bit … messy.

I propose that BeanAccessor gets a new constructor which accepts isGetterName, 
getGetterName and setterName as parameters, that the current constructor can 
invoke with the current values. That way, our new non-prefixed BeanAccessor 
implementation could just subclass BeanAccessor and wouldn't have to touch any 
logic related to reading or setting property values, it would only pass in our 
preferred property name structure.

At least that's one idea. If you agree with this, I'd be more than happy to 
submit a PR with that modification once your PR has been merged.

Cheers, and thanks again,
- hugi



> On 4 Feb 2019, at 13:12, Nikita Timofeev  wrote:
> 
> Hi Maik.
> 
> As I'm the one researched this, let me answer :) I failed to make
> BeanAccessor pluggable last time because I realized that it's deep
> inside code not managed by Cayenne DI.
> But looking again at it I wonder will this straightforward solution
> [1] solve your problems?
> And I'm really interested what is your use case? Do you perform lots
> of in-memory filtering and/or calculations using Cayenne Expressions?
> 
> [1] 
> https://github.com/apache/cayenne/pull/363/files?utf8=✓=unified#diff-4f928c7d2ac0e22cabde0c9732de774fR214
> 
> On Thu, Jan 31, 2019 at 7:22 PM Maik Musall  wrote:
>> 
>> Hi Andrus,
>> 
>> did you have a chance to look at this yet? The reason I ask is that our 
>> application hit the memory limit this week again (-Xmx at 96 GB), and 
>> according to some profiling, almost half of that is used up by HashMap 
>> nodes. So we're really eager to upgrade to Cayenne 4.1 to be able to use 
>> field-based DataObjects, but this is preventing us from going ahead.
>> 
>> Thanks
>> Maik
>> 
>> 
>> 
>>> Am 25.09.2018 um 16:23 schrieb Andrus Adamchik :
>>> 
 "Should Cayenne by default work without prefixed accessors".
>>> 
>>> My answer to this : "By default, no. As a fallback or a custom strategy, 
>>> possibly."
>>> 
>>> I actually agree about Java beans. They are almost irrelevant now. And I 
>>> wish Java gets "data classes" and some transparent form of "properties".
>>> 
>>> As things stand now though, there's no common established alternative based 
>>> on a naming convention that we can safely hardcode without causing grief 
>>> for someone because they didn't expect that their method would be called 
>>> when evaluating expressions. Hence my preference for a DI fix.
>>> 
>>> So how about this... Unless someone else steps in by then, let me 
>>> brainstorm it with Nikita a couple of weeks from now and see if we can do a 
>>> DI solution. It is not nearly as involved as it appears.
>>> 
>>> Andrus
>>> 
>>> 
 On Sep 25, 2018, at 9:59 AM, Hugi Thordarson  wrote:
 
 Hi Andrus and thanks for the reply,
 
 allowing replacement of the entire reflection strategy is certainly nice 
 and would allow me to make the customizations I need.
 
 However, if it's OK with you, rather than discuss implementation details, 
 I'd like to take two steps back and revert to the more philosophical 
 design question of:
 
 "Should Cayenne by default work without prefixed accessors".
 
 What is there to be lost or gained from keeping or abandoning the 
 prefix-requirement?
 
 I believe I can safely assert that Cayenne works fine without accessor 
 prefixes, since I've used it that way on dozens of projects, so it looks 
 like a somewhat arbitrary limitation. It's only with the introduction of 
 field based DOs that we get a problem in a very isolated part of the 
 framework.
 
 It seems to me that the java ecosystem is moving towards more modern API 
 design—we've even got the architect of the Java language calling the 
 bean-style "at best a questionable -- and certainly overused -- API naming 
 convention" [http://cr.openjdk.java.net/~briangoetz/amber/datum.html 
 ] (pardon the 
 appeal to authority, but considering where it comes from, it's probably a 
 good barometer for where java language and API design is headed).
 
 I'd say that the framework would be well served and future-proofed by 
 dropping the requirement for hard-coded accessor prefixes as a baked in 
 requirement.
 
 Cheers,
 - hugi

Re: Allowing property getters without a "get" prefix on DataObjects

[Nikita Timofeev]

Hi Maik.

As I'm the one researched this, let me answer :) I failed to make
BeanAccessor pluggable last time because I realized that it's deep
inside code not managed by Cayenne DI.
But looking again at it I wonder will this straightforward solution
[1] solve your problems?
And I'm really interested what is your use case? Do you perform lots
of in-memory filtering and/or calculations using Cayenne Expressions?

[1] 
https://github.com/apache/cayenne/pull/363/files?utf8=✓=unified#diff-4f928c7d2ac0e22cabde0c9732de774fR214

On Thu, Jan 31, 2019 at 7:22 PM Maik Musall  wrote:
>
> Hi Andrus,
>
> did you have a chance to look at this yet? The reason I ask is that our 
> application hit the memory limit this week again (-Xmx at 96 GB), and 
> according to some profiling, almost half of that is used up by HashMap nodes. 
> So we're really eager to upgrade to Cayenne 4.1 to be able to use field-based 
> DataObjects, but this is preventing us from going ahead.
>
> Thanks
> Maik
>
>
>
> > Am 25.09.2018 um 16:23 schrieb Andrus Adamchik :
> >
> >> "Should Cayenne by default work without prefixed accessors".
> >
> > My answer to this : "By default, no. As a fallback or a custom strategy, 
> > possibly."
> >
> > I actually agree about Java beans. They are almost irrelevant now. And I 
> > wish Java gets "data classes" and some transparent form of "properties".
> >
> > As things stand now though, there's no common established alternative based 
> > on a naming convention that we can safely hardcode without causing grief 
> > for someone because they didn't expect that their method would be called 
> > when evaluating expressions. Hence my preference for a DI fix.
> >
> > So how about this... Unless someone else steps in by then, let me 
> > brainstorm it with Nikita a couple of weeks from now and see if we can do a 
> > DI solution. It is not nearly as involved as it appears.
> >
> > Andrus
> >
> >
> >> On Sep 25, 2018, at 9:59 AM, Hugi Thordarson  wrote:
> >>
> >> Hi Andrus and thanks for the reply,
> >>
> >> allowing replacement of the entire reflection strategy is certainly nice 
> >> and would allow me to make the customizations I need.
> >>
> >> However, if it's OK with you, rather than discuss implementation details, 
> >> I'd like to take two steps back and revert to the more philosophical 
> >> design question of:
> >>
> >> "Should Cayenne by default work without prefixed accessors".
> >>
> >> What is there to be lost or gained from keeping or abandoning the 
> >> prefix-requirement?
> >>
> >> I believe I can safely assert that Cayenne works fine without accessor 
> >> prefixes, since I've used it that way on dozens of projects, so it looks 
> >> like a somewhat arbitrary limitation. It's only with the introduction of 
> >> field based DOs that we get a problem in a very isolated part of the 
> >> framework.
> >>
> >> It seems to me that the java ecosystem is moving towards more modern API 
> >> design—we've even got the architect of the Java language calling the 
> >> bean-style "at best a questionable -- and certainly overused -- API naming 
> >> convention" [http://cr.openjdk.java.net/~briangoetz/amber/datum.html 
> >> ] (pardon the 
> >> appeal to authority, but considering where it comes from, it's probably a 
> >> good barometer for where java language and API design is headed).
> >>
> >> I'd say that the framework would be well served and future-proofed by 
> >> dropping the requirement for hard-coded accessor prefixes as a baked in 
> >> requirement.
> >>
> >> Cheers,
> >> - hugi
> >>
> >>
> >>
> >>> On 25 Sep 2018, at 11:15, Andrus Adamchik  wrote:
> >>>
> >>> Hi Hugi,
> >>>
> >>> My vote would be to do it right. There is a positive side effect that the 
> >>> entire reflection strategy suddenly becomes customizable.
> >>>
> >>> Andrus
> >>>
> >>>
>  On Sep 25, 2018, at 7:11 AM, Hugi Thordarson  wrote:
> 
>  Hi Andrus, and y'all.
> 
>  I've been looking into this and it seems like a rather large change to 
>  allow something relatively simple (allowing DataObjects to have accessor 
>  methods that don't start with a "get"-prefix).
> 
>  Would people be diametrically opposed to just changing BeanAccessor so 
>  that it seeks for a non-prefixed method if a prefixed one isn't found? 
>  That modification is minimal and shouldn't affect any current users, so 
>  I can think of.
> 
>  Cheers,
>  - hugi
> 
> 
> 
> > On 20 Sep 2018, at 16:08, Andrus Adamchik  
> > wrote:
> >
> > Hi Maik,
> >
> > In Cayenne a canonical way to override services is via DI. A PR that 
> > follows that approach has a good chance of acceptance.
> >
> > From a quick glance, I wonder if this new DI endpoint should be a 
> > factory of ClassDescriptorMap (which is currently lazily created inside 
> > EntityResolver). We can't make ClassDescriptorMap itself DI-managed 

Re: Allowing property getters without a "get" prefix on DataObjects

[Maik Musall]

Hi Andrus,

did you have a chance to look at this yet? The reason I ask is that our 
application hit the memory limit this week again (-Xmx at 96 GB), and according 
to some profiling, almost half of that is used up by HashMap nodes. So we're 
really eager to upgrade to Cayenne 4.1 to be able to use field-based 
DataObjects, but this is preventing us from going ahead.

Thanks
Maik



> Am 25.09.2018 um 16:23 schrieb Andrus Adamchik :
> 
>> "Should Cayenne by default work without prefixed accessors".
> 
> My answer to this : "By default, no. As a fallback or a custom strategy, 
> possibly."
> 
> I actually agree about Java beans. They are almost irrelevant now. And I wish 
> Java gets "data classes" and some transparent form of "properties". 
> 
> As things stand now though, there's no common established alternative based 
> on a naming convention that we can safely hardcode without causing grief for 
> someone because they didn't expect that their method would be called when 
> evaluating expressions. Hence my preference for a DI fix.
> 
> So how about this... Unless someone else steps in by then, let me brainstorm 
> it with Nikita a couple of weeks from now and see if we can do a DI solution. 
> It is not nearly as involved as it appears.
> 
> Andrus
> 
> 
>> On Sep 25, 2018, at 9:59 AM, Hugi Thordarson  wrote:
>> 
>> Hi Andrus and thanks for the reply,
>> 
>> allowing replacement of the entire reflection strategy is certainly nice and 
>> would allow me to make the customizations I need.
>> 
>> However, if it's OK with you, rather than discuss implementation details, 
>> I'd like to take two steps back and revert to the more philosophical design 
>> question of:
>> 
>> "Should Cayenne by default work without prefixed accessors".
>> 
>> What is there to be lost or gained from keeping or abandoning the 
>> prefix-requirement?
>> 
>> I believe I can safely assert that Cayenne works fine without accessor 
>> prefixes, since I've used it that way on dozens of projects, so it looks 
>> like a somewhat arbitrary limitation. It's only with the introduction of 
>> field based DOs that we get a problem in a very isolated part of the 
>> framework.
>> 
>> It seems to me that the java ecosystem is moving towards more modern API 
>> design—we've even got the architect of the Java language calling the 
>> bean-style "at best a questionable -- and certainly overused -- API naming 
>> convention" [http://cr.openjdk.java.net/~briangoetz/amber/datum.html 
>> ] (pardon the 
>> appeal to authority, but considering where it comes from, it's probably a 
>> good barometer for where java language and API design is headed).
>> 
>> I'd say that the framework would be well served and future-proofed by 
>> dropping the requirement for hard-coded accessor prefixes as a baked in 
>> requirement.
>> 
>> Cheers,
>> - hugi
>> 
>> 
>> 
>>> On 25 Sep 2018, at 11:15, Andrus Adamchik  wrote:
>>> 
>>> Hi Hugi,
>>> 
>>> My vote would be to do it right. There is a positive side effect that the 
>>> entire reflection strategy suddenly becomes customizable.
>>> 
>>> Andrus
>>> 
>>> 
 On Sep 25, 2018, at 7:11 AM, Hugi Thordarson  wrote:
 
 Hi Andrus, and y'all.
 
 I've been looking into this and it seems like a rather large change to 
 allow something relatively simple (allowing DataObjects to have accessor 
 methods that don't start with a "get"-prefix).
 
 Would people be diametrically opposed to just changing BeanAccessor so 
 that it seeks for a non-prefixed method if a prefixed one isn't found? 
 That modification is minimal and shouldn't affect any current users, so I 
 can think of.
 
 Cheers,
 - hugi
 
 
 
> On 20 Sep 2018, at 16:08, Andrus Adamchik  wrote:
> 
> Hi Maik,
> 
> In Cayenne a canonical way to override services is via DI. A PR that 
> follows that approach has a good chance of acceptance. 
> 
> From a quick glance, I wonder if this new DI endpoint should be a factory 
> of ClassDescriptorMap (which is currently lazily created inside 
> EntityResolver). We can't make ClassDescriptorMap itself DI-managed as it 
> depends on the mapping state, but a factory for it can be a DI singleton. 
> Inside your custom factory (a few levels down actually) you can provide a 
> subclass of BeanAccessor (maybe also via its own DI factory?).
> 
> Andrus
> 
> 
>> On Sep 19, 2018, at 8:35 AM, Maik Musall  wrote:
>> 
>> Hi all,
>> 
>> I'd like to pull up this discussion from one year ago again. I'm 
>> currently running 4.0 and testing upgrading to 4.1 using field-based 
>> DataObjects, and I'm hitting the hard-coded prefixes in BeanAccessor 
>> that prevent me from proceeding.
>> 
>> Yes, in theory I could sigh, yield, and use "get" prefixes, but not only 
>> do I dislike introducing the "get" boilerplate 

Re: Allowing property getters without a "get" prefix on DataObjects

[David Feshbach]

IIRC, EOF/Wonder allowed you to implement NSKeyValueCoding and the
Utilities class would call valueForKey instead of looking up methods/fields
via reflection. Something similar that would allow you to write/generate
your own readProperty method might work for Cayenne.

On Tue, Sep 25, 2018 at 3:28 PM Maik Musall  wrote:

>
>
> > Am 25.09.2018 um 16:59 schrieb John Huss :
> >
> > On Tue, Sep 25, 2018 at 9:50 AM Maik Musall  > wrote:
> >
> >>
> >>
> >>> Am 25.09.2018 um 16:23 schrieb Andrus Adamchik  >:
> >>>
>  "Should Cayenne by default work without prefixed accessors".
> >>>
> >>>
> >>> So how about this... Unless someone else steps in by then, let me
> >> brainstorm it with Nikita a couple of weeks from now and see if we can
> do a
> >> DI solution. It is not nearly as involved as it appears.
> >>
> >> I would be very happy about that! :)
> >>
> >> And once that's there, one way to implement a BeanAccessor alternative
> >> could perhaps be one that is tailored towards field-based DataObjects,
> >> accessing the fields directly without using reflection? If possible,
> that
> >> could present another noticable performance win.
> >>
> >
> > FWIW, I would consider this a non-goal since it would bypass the getter
> > method which may have custom logic (like returning a default value or
> > something).
>
> I didn't mean this to become a standard way, but once the DI point is
> there,
> it's easy to rock your own implementation if you know it matches your use
> case.
>
> Maik
>
>

Re: Allowing property getters without a "get" prefix on DataObjects

[Maik Musall]

> Am 25.09.2018 um 16:59 schrieb John Huss :
> 
> On Tue, Sep 25, 2018 at 9:50 AM Maik Musall  > wrote:
> 
>> 
>> 
>>> Am 25.09.2018 um 16:23 schrieb Andrus Adamchik :
>>> 
 "Should Cayenne by default work without prefixed accessors".
>>> 
>>> 
>>> So how about this... Unless someone else steps in by then, let me
>> brainstorm it with Nikita a couple of weeks from now and see if we can do a
>> DI solution. It is not nearly as involved as it appears.
>> 
>> I would be very happy about that! :)
>> 
>> And once that's there, one way to implement a BeanAccessor alternative
>> could perhaps be one that is tailored towards field-based DataObjects,
>> accessing the fields directly without using reflection? If possible, that
>> could present another noticable performance win.
>> 
> 
> FWIW, I would consider this a non-goal since it would bypass the getter
> method which may have custom logic (like returning a default value or
> something).

I didn't mean this to become a standard way, but once the DI point is there,
it's easy to rock your own implementation if you know it matches your use case.

Maik

Re: Allowing property getters without a "get" prefix on DataObjects

[Hugi Thordarson]

>> "Should Cayenne by default work without prefixed accessors".
> 
> My answer to this : "By default, no. As a fallback or a custom strategy, 
> possibly."

Fair enough.

> I actually agree about Java beans. They are almost irrelevant now. And I wish 
> Java gets "data classes" and some transparent form of "properties". 
> 
> As things stand now though, there's no common established alternative based 
> on a naming convention that we can safely hardcode without causing grief for 
> someone because they didn't expect that their method would be called when 
> evaluating expressions. Hence my preference for a DI fix.
> 
> So how about this... Unless someone else steps in by then, let me brainstorm 
> it with Nikita a couple of weeks from now and see if we can do a DI solution. 
> It is not nearly as involved as it appears.

Sounds awesome :). I wish I could be the one to step forward given I'm the one 
raising a fuss, but after looking at the changes involved and given my 
knowledge, I'm a bit hesitant to start hacking away on such a core part of 
Cayenne's design at this time.

Cheers,
- hugi


> 
> Andrus
> 
> 
>> On Sep 25, 2018, at 9:59 AM, Hugi Thordarson  wrote:
>> 
>> Hi Andrus and thanks for the reply,
>> 
>> allowing replacement of the entire reflection strategy is certainly nice and 
>> would allow me to make the customizations I need.
>> 
>> However, if it's OK with you, rather than discuss implementation details, 
>> I'd like to take two steps back and revert to the more philosophical design 
>> question of:
>> 
>> "Should Cayenne by default work without prefixed accessors".
>> 
>> What is there to be lost or gained from keeping or abandoning the 
>> prefix-requirement?
>> 
>> I believe I can safely assert that Cayenne works fine without accessor 
>> prefixes, since I've used it that way on dozens of projects, so it looks 
>> like a somewhat arbitrary limitation. It's only with the introduction of 
>> field based DOs that we get a problem in a very isolated part of the 
>> framework.
>> 
>> It seems to me that the java ecosystem is moving towards more modern API 
>> design—we've even got the architect of the Java language calling the 
>> bean-style "at best a questionable -- and certainly overused -- API naming 
>> convention" [http://cr.openjdk.java.net/~briangoetz/amber/datum.html 
>> ] (pardon the 
>> appeal to authority, but considering where it comes from, it's probably a 
>> good barometer for where java language and API design is headed).
>> 
>> I'd say that the framework would be well served and future-proofed by 
>> dropping the requirement for hard-coded accessor prefixes as a baked in 
>> requirement.
>> 
>> Cheers,
>> - hugi
>> 
>> 
>> 
>>> On 25 Sep 2018, at 11:15, Andrus Adamchik  wrote:
>>> 
>>> Hi Hugi,
>>> 
>>> My vote would be to do it right. There is a positive side effect that the 
>>> entire reflection strategy suddenly becomes customizable.
>>> 
>>> Andrus
>>> 
>>> 
 On Sep 25, 2018, at 7:11 AM, Hugi Thordarson  wrote:
 
 Hi Andrus, and y'all.
 
 I've been looking into this and it seems like a rather large change to 
 allow something relatively simple (allowing DataObjects to have accessor 
 methods that don't start with a "get"-prefix).
 
 Would people be diametrically opposed to just changing BeanAccessor so 
 that it seeks for a non-prefixed method if a prefixed one isn't found? 
 That modification is minimal and shouldn't affect any current users, so I 
 can think of.
 
 Cheers,
 - hugi
 
 
 
> On 20 Sep 2018, at 16:08, Andrus Adamchik  wrote:
> 
> Hi Maik,
> 
> In Cayenne a canonical way to override services is via DI. A PR that 
> follows that approach has a good chance of acceptance. 
> 
> From a quick glance, I wonder if this new DI endpoint should be a factory 
> of ClassDescriptorMap (which is currently lazily created inside 
> EntityResolver). We can't make ClassDescriptorMap itself DI-managed as it 
> depends on the mapping state, but a factory for it can be a DI singleton. 
> Inside your custom factory (a few levels down actually) you can provide a 
> subclass of BeanAccessor (maybe also via its own DI factory?).
> 
> Andrus
> 
> 
>> On Sep 19, 2018, at 8:35 AM, Maik Musall  wrote:
>> 
>> Hi all,
>> 
>> I'd like to pull up this discussion from one year ago again. I'm 
>> currently running 4.0 and testing upgrading to 4.1 using field-based 
>> DataObjects, and I'm hitting the hard-coded prefixes in BeanAccessor 
>> that prevent me from proceeding.
>> 
>> Yes, in theory I could sigh, yield, and use "get" prefixes, but not only 
>> do I dislike introducing the "get" boilerplate everywhere. I am also 
>> somewhat reluctant to make a refactoring touching some 800+ files in my 
>> project. To be honest, I'd rather patch 

Re: Allowing property getters without a "get" prefix on DataObjects

[John Huss]

On Tue, Sep 25, 2018 at 9:50 AM Maik Musall  wrote:

>
>
> > Am 25.09.2018 um 16:23 schrieb Andrus Adamchik :
> >
> >> "Should Cayenne by default work without prefixed accessors".
> >
> >
> > So how about this... Unless someone else steps in by then, let me
> brainstorm it with Nikita a couple of weeks from now and see if we can do a
> DI solution. It is not nearly as involved as it appears.
>
> I would be very happy about that! :)
>
> And once that's there, one way to implement a BeanAccessor alternative
> could perhaps be one that is tailored towards field-based DataObjects,
> accessing the fields directly without using reflection? If possible, that
> could present another noticable performance win.
>

FWIW, I would consider this a non-goal since it would bypass the getter
method which may have custom logic (like returning a default value or
something).


>
> Maik
>
>

Re: Allowing property getters without a "get" prefix on DataObjects

[Maik Musall]

> Am 25.09.2018 um 16:23 schrieb Andrus Adamchik :
> 
>> "Should Cayenne by default work without prefixed accessors".
> 
> 
> So how about this... Unless someone else steps in by then, let me brainstorm 
> it with Nikita a couple of weeks from now and see if we can do a DI solution. 
> It is not nearly as involved as it appears.

I would be very happy about that! :)

And once that's there, one way to implement a BeanAccessor alternative could 
perhaps be one that is tailored towards field-based DataObjects, accessing the 
fields directly without using reflection? If possible, that could present 
another noticable performance win.

Maik

Re: Allowing property getters without a "get" prefix on DataObjects

[Andrus Adamchik]

> "Should Cayenne by default work without prefixed accessors".

My answer to this : "By default, no. As a fallback or a custom strategy, 
possibly."

I actually agree about Java beans. They are almost irrelevant now. And I wish 
Java gets "data classes" and some transparent form of "properties". 

As things stand now though, there's no common established alternative based on 
a naming convention that we can safely hardcode without causing grief for 
someone because they didn't expect that their method would be called when 
evaluating expressions. Hence my preference for a DI fix.

So how about this... Unless someone else steps in by then, let me brainstorm it 
with Nikita a couple of weeks from now and see if we can do a DI solution. It 
is not nearly as involved as it appears.

Andrus


> On Sep 25, 2018, at 9:59 AM, Hugi Thordarson  wrote:
> 
> Hi Andrus and thanks for the reply,
> 
> allowing replacement of the entire reflection strategy is certainly nice and 
> would allow me to make the customizations I need.
> 
> However, if it's OK with you, rather than discuss implementation details, I'd 
> like to take two steps back and revert to the more philosophical design 
> question of:
> 
> "Should Cayenne by default work without prefixed accessors".
> 
> What is there to be lost or gained from keeping or abandoning the 
> prefix-requirement?
> 
> I believe I can safely assert that Cayenne works fine without accessor 
> prefixes, since I've used it that way on dozens of projects, so it looks like 
> a somewhat arbitrary limitation. It's only with the introduction of field 
> based DOs that we get a problem in a very isolated part of the framework.
> 
> It seems to me that the java ecosystem is moving towards more modern API 
> design—we've even got the architect of the Java language calling the 
> bean-style "at best a questionable -- and certainly overused -- API naming 
> convention" [http://cr.openjdk.java.net/~briangoetz/amber/datum.html 
> ] (pardon the appeal 
> to authority, but considering where it comes from, it's probably a good 
> barometer for where java language and API design is headed).
> 
> I'd say that the framework would be well served and future-proofed by 
> dropping the requirement for hard-coded accessor prefixes as a baked in 
> requirement.
> 
> Cheers,
> - hugi
> 
> 
> 
>> On 25 Sep 2018, at 11:15, Andrus Adamchik  wrote:
>> 
>> Hi Hugi,
>> 
>> My vote would be to do it right. There is a positive side effect that the 
>> entire reflection strategy suddenly becomes customizable.
>> 
>> Andrus
>> 
>> 
>>> On Sep 25, 2018, at 7:11 AM, Hugi Thordarson  wrote:
>>> 
>>> Hi Andrus, and y'all.
>>> 
>>> I've been looking into this and it seems like a rather large change to 
>>> allow something relatively simple (allowing DataObjects to have accessor 
>>> methods that don't start with a "get"-prefix).
>>> 
>>> Would people be diametrically opposed to just changing BeanAccessor so that 
>>> it seeks for a non-prefixed method if a prefixed one isn't found? That 
>>> modification is minimal and shouldn't affect any current users, so I can 
>>> think of.
>>> 
>>> Cheers,
>>> - hugi
>>> 
>>> 
>>> 
 On 20 Sep 2018, at 16:08, Andrus Adamchik  wrote:
 
 Hi Maik,
 
 In Cayenne a canonical way to override services is via DI. A PR that 
 follows that approach has a good chance of acceptance. 
 
 From a quick glance, I wonder if this new DI endpoint should be a factory 
 of ClassDescriptorMap (which is currently lazily created inside 
 EntityResolver). We can't make ClassDescriptorMap itself DI-managed as it 
 depends on the mapping state, but a factory for it can be a DI singleton. 
 Inside your custom factory (a few levels down actually) you can provide a 
 subclass of BeanAccessor (maybe also via its own DI factory?).
 
 Andrus
 
 
> On Sep 19, 2018, at 8:35 AM, Maik Musall  wrote:
> 
> Hi all,
> 
> I'd like to pull up this discussion from one year ago again. I'm 
> currently running 4.0 and testing upgrading to 4.1 using field-based 
> DataObjects, and I'm hitting the hard-coded prefixes in BeanAccessor that 
> prevent me from proceeding.
> 
> Yes, in theory I could sigh, yield, and use "get" prefixes, but not only 
> do I dislike introducing the "get" boilerplate everywhere. I am also 
> somewhat reluctant to make a refactoring touching some 800+ files in my 
> project. To be honest, I'd rather patch BeanAccessor to personal taste 
> and deal with the consequences.
> 
> BeanAccessor is currently always called by it's constructor. In addition 
> to the options Hugi described in his original mail in this thread, I 
> could also imagine a way to modify this to be able to inject a custom 
> Accessor implementation as an alternative. What do you think?
> 
> And… what would happen if someone would 

Re: Allowing property getters without a "get" prefix on DataObjects

[Hugi Thordarson]

Hi Andrus and thanks for the reply,

allowing replacement of the entire reflection strategy is certainly nice and 
would allow me to make the customizations I need.

However, if it's OK with you, rather than discuss implementation details, I'd 
like to take two steps back and revert to the more philosophical design 
question of:

"Should Cayenne by default work without prefixed accessors".

What is there to be lost or gained from keeping or abandoning the 
prefix-requirement?

I believe I can safely assert that Cayenne works fine without accessor 
prefixes, since I've used it that way on dozens of projects, so it looks like a 
somewhat arbitrary limitation. It's only with the introduction of field based 
DOs that we get a problem in a very isolated part of the framework.

It seems to me that the java ecosystem is moving towards more modern API 
design—we've even got the architect of the Java language calling the bean-style 
"at best a questionable -- and certainly overused -- API naming convention" 
[http://cr.openjdk.java.net/~briangoetz/amber/datum.html 
] (pardon the appeal 
to authority, but considering where it comes from, it's probably a good 
barometer for where java language and API design is headed).

I'd say that the framework would be well served and future-proofed by dropping 
the requirement for hard-coded accessor prefixes as a baked in requirement.

Cheers,
- hugi



> On 25 Sep 2018, at 11:15, Andrus Adamchik  wrote:
> 
> Hi Hugi,
> 
> My vote would be to do it right. There is a positive side effect that the 
> entire reflection strategy suddenly becomes customizable.
> 
> Andrus
> 
> 
>> On Sep 25, 2018, at 7:11 AM, Hugi Thordarson  wrote:
>> 
>> Hi Andrus, and y'all.
>> 
>> I've been looking into this and it seems like a rather large change to allow 
>> something relatively simple (allowing DataObjects to have accessor methods 
>> that don't start with a "get"-prefix).
>> 
>> Would people be diametrically opposed to just changing BeanAccessor so that 
>> it seeks for a non-prefixed method if a prefixed one isn't found? That 
>> modification is minimal and shouldn't affect any current users, so I can 
>> think of.
>> 
>> Cheers,
>> - hugi
>> 
>> 
>> 
>>> On 20 Sep 2018, at 16:08, Andrus Adamchik  wrote:
>>> 
>>> Hi Maik,
>>> 
>>> In Cayenne a canonical way to override services is via DI. A PR that 
>>> follows that approach has a good chance of acceptance. 
>>> 
>>> From a quick glance, I wonder if this new DI endpoint should be a factory 
>>> of ClassDescriptorMap (which is currently lazily created inside 
>>> EntityResolver). We can't make ClassDescriptorMap itself DI-managed as it 
>>> depends on the mapping state, but a factory for it can be a DI singleton. 
>>> Inside your custom factory (a few levels down actually) you can provide a 
>>> subclass of BeanAccessor (maybe also via its own DI factory?).
>>> 
>>> Andrus
>>> 
>>> 
 On Sep 19, 2018, at 8:35 AM, Maik Musall  wrote:
 
 Hi all,
 
 I'd like to pull up this discussion from one year ago again. I'm currently 
 running 4.0 and testing upgrading to 4.1 using field-based DataObjects, 
 and I'm hitting the hard-coded prefixes in BeanAccessor that prevent me 
 from proceeding.
 
 Yes, in theory I could sigh, yield, and use "get" prefixes, but not only 
 do I dislike introducing the "get" boilerplate everywhere. I am also 
 somewhat reluctant to make a refactoring touching some 800+ files in my 
 project. To be honest, I'd rather patch BeanAccessor to personal taste and 
 deal with the consequences.
 
 BeanAccessor is currently always called by it's constructor. In addition 
 to the options Hugi described in his original mail in this thread, I could 
 also imagine a way to modify this to be able to inject a custom Accessor 
 implementation as an alternative. What do you think?
 
 And… what would happen if someone would submit a pull request actually 
 implementing one of these options? :-)
 
 Cheers
 Maik
 
 
> Am 26.09.2017 um 15:32 schrieb Hugi Thordarson :
> 
> Hi Michael,
> 
> thanks for an honest attempt to convince me. Hard sell, though. :)
> 
> I use a lot of 3rd party libraries and I've only hit one time where using 
> the bean spec was necessary — JasperReports. That was easily fixed by 
> providing *BeanInfo classes, in accordance with the Bean spec. But 
> Cayenne doesn't really follow the Java Bean Spec, it just hardcodes "is", 
> "get" and "set".
> 
> As for the Eclipse thing… Well. A standard DataObject already has five 
> methods prefixed with "get" so that list is questionable. And I don't 
> miss this functionality.
> 
> I think it's important to note that the change I'm proposing would not 
> affect those who choose to add the prefix. It just accommodates those of 
> us who choose 

Re: Allowing property getters without a "get" prefix on DataObjects

[Andrus Adamchik]

Hi Hugi,

My vote would be to do it right. There is a positive side effect that the 
entire reflection strategy suddenly becomes customizable.

Andrus


> On Sep 25, 2018, at 7:11 AM, Hugi Thordarson  wrote:
> 
> Hi Andrus, and y'all.
> 
> I've been looking into this and it seems like a rather large change to allow 
> something relatively simple (allowing DataObjects to have accessor methods 
> that don't start with a "get"-prefix).
> 
> Would people be diametrically opposed to just changing BeanAccessor so that 
> it seeks for a non-prefixed method if a prefixed one isn't found? That 
> modification is minimal and shouldn't affect any current users, so I can 
> think of.
> 
> Cheers,
> - hugi
> 
> 
> 
>> On 20 Sep 2018, at 16:08, Andrus Adamchik  wrote:
>> 
>> Hi Maik,
>> 
>> In Cayenne a canonical way to override services is via DI. A PR that follows 
>> that approach has a good chance of acceptance. 
>> 
>> From a quick glance, I wonder if this new DI endpoint should be a factory of 
>> ClassDescriptorMap (which is currently lazily created inside 
>> EntityResolver). We can't make ClassDescriptorMap itself DI-managed as it 
>> depends on the mapping state, but a factory for it can be a DI singleton. 
>> Inside your custom factory (a few levels down actually) you can provide a 
>> subclass of BeanAccessor (maybe also via its own DI factory?).
>> 
>> Andrus
>> 
>> 
>>> On Sep 19, 2018, at 8:35 AM, Maik Musall  wrote:
>>> 
>>> Hi all,
>>> 
>>> I'd like to pull up this discussion from one year ago again. I'm currently 
>>> running 4.0 and testing upgrading to 4.1 using field-based DataObjects, and 
>>> I'm hitting the hard-coded prefixes in BeanAccessor that prevent me from 
>>> proceeding.
>>> 
>>> Yes, in theory I could sigh, yield, and use "get" prefixes, but not only do 
>>> I dislike introducing the "get" boilerplate everywhere. I am also somewhat 
>>> reluctant to make a refactoring touching some 800+ files in my project. To 
>>> be honest, I'd rather patch BeanAccessor to personal taste and deal with 
>>> the consequences.
>>> 
>>> BeanAccessor is currently always called by it's constructor. In addition to 
>>> the options Hugi described in his original mail in this thread, I could 
>>> also imagine a way to modify this to be able to inject a custom Accessor 
>>> implementation as an alternative. What do you think?
>>> 
>>> And… what would happen if someone would submit a pull request actually 
>>> implementing one of these options? :-)
>>> 
>>> Cheers
>>> Maik
>>> 
>>> 
 Am 26.09.2017 um 15:32 schrieb Hugi Thordarson :
 
 Hi Michael,
 
 thanks for an honest attempt to convince me. Hard sell, though. :)
 
 I use a lot of 3rd party libraries and I've only hit one time where using 
 the bean spec was necessary — JasperReports. That was easily fixed by 
 providing *BeanInfo classes, in accordance with the Bean spec. But Cayenne 
 doesn't really follow the Java Bean Spec, it just hardcodes "is", "get" 
 and "set".
 
 As for the Eclipse thing… Well. A standard DataObject already has five 
 methods prefixed with "get" so that list is questionable. And I don't miss 
 this functionality.
 
 I think it's important to note that the change I'm proposing would not 
 affect those who choose to add the prefix. It just accommodates those of 
 us who choose not to, thus expanding the audience of the framework.
 
 Cheers,
 - hugi
 
 
 
> On 26 Sep 2017, at 12:01, Michael Gentry  wrote:
> 
> Hi Hugi,
> 
> Let me try to sell you on the "get" prefix.  :-)
> 
> (I did a lot of WebObjects/EOF in the past, in Objective-C and Java, so I
> understand the reluctance.)
> 
> * The "get" prefix is part of the JavaBeans standard/contract.  With the
> exception of "is" for booleans (with a little "b").
> 
> * There are tons of Java frameworks out there that expect and utilize the
> JavaBeans contract, so it is great for folding external frameworks into
> your code.  Or folding Cayenne into other frameworks, such as Tapestry.  I
> can specify Cayenne object/relationship paths in Tapestry (and other
> frameworks) such as
> t:value="currentItem.resourceSummary.grossCost.costs.continuingFootnote"
> (real example).  Since Tapestry expects the JavaBeans contract and Cayenne
> provides it, this works flawlessly.
> 
> * In Eclipse (and others, I'm sure) I can do anObject.get[pause or
> control-space] and see all the getters associated with that object.
> Without the get prefix, they are spread out a-z and therefore you can't 
> get
> as concise a list.
> 
> mrg
> 
> 
> On Tue, Sep 26, 2017 at 7:02 AM, Hugi Thordarson  wrote:
> 
>> Hi all
>> 
>> Touching on an old subject that has now become more important with
>> field-based Data Objects.
>> 
>> All of my DataObjects use accessor methods 

Re: Allowing property getters without a "get" prefix on DataObjects

[Hugi Thordarson]

Hi Andrus, and y'all.

I've been looking into this and it seems like a rather large change to allow 
something relatively simple (allowing DataObjects to have accessor methods that 
don't start with a "get"-prefix).

Would people be diametrically opposed to just changing BeanAccessor so that it 
seeks for a non-prefixed method if a prefixed one isn't found? That 
modification is minimal and shouldn't affect any current users, so I can think 
of.

Cheers,
- hugi



> On 20 Sep 2018, at 16:08, Andrus Adamchik  wrote:
> 
> Hi Maik,
> 
> In Cayenne a canonical way to override services is via DI. A PR that follows 
> that approach has a good chance of acceptance. 
> 
> From a quick glance, I wonder if this new DI endpoint should be a factory of 
> ClassDescriptorMap (which is currently lazily created inside EntityResolver). 
> We can't make ClassDescriptorMap itself DI-managed as it depends on the 
> mapping state, but a factory for it can be a DI singleton. Inside your custom 
> factory (a few levels down actually) you can provide a subclass of 
> BeanAccessor (maybe also via its own DI factory?).
> 
> Andrus
> 
> 
>> On Sep 19, 2018, at 8:35 AM, Maik Musall  wrote:
>> 
>> Hi all,
>> 
>> I'd like to pull up this discussion from one year ago again. I'm currently 
>> running 4.0 and testing upgrading to 4.1 using field-based DataObjects, and 
>> I'm hitting the hard-coded prefixes in BeanAccessor that prevent me from 
>> proceeding.
>> 
>> Yes, in theory I could sigh, yield, and use "get" prefixes, but not only do 
>> I dislike introducing the "get" boilerplate everywhere. I am also somewhat 
>> reluctant to make a refactoring touching some 800+ files in my project. To 
>> be honest, I'd rather patch BeanAccessor to personal taste and deal with the 
>> consequences.
>> 
>> BeanAccessor is currently always called by it's constructor. In addition to 
>> the options Hugi described in his original mail in this thread, I could also 
>> imagine a way to modify this to be able to inject a custom Accessor 
>> implementation as an alternative. What do you think?
>> 
>> And… what would happen if someone would submit a pull request actually 
>> implementing one of these options? :-)
>> 
>> Cheers
>> Maik
>> 
>> 
>>> Am 26.09.2017 um 15:32 schrieb Hugi Thordarson :
>>> 
>>> Hi Michael,
>>> 
>>> thanks for an honest attempt to convince me. Hard sell, though. :)
>>> 
>>> I use a lot of 3rd party libraries and I've only hit one time where using 
>>> the bean spec was necessary — JasperReports. That was easily fixed by 
>>> providing *BeanInfo classes, in accordance with the Bean spec. But Cayenne 
>>> doesn't really follow the Java Bean Spec, it just hardcodes "is", "get" and 
>>> "set".
>>> 
>>> As for the Eclipse thing… Well. A standard DataObject already has five 
>>> methods prefixed with "get" so that list is questionable. And I don't miss 
>>> this functionality.
>>> 
>>> I think it's important to note that the change I'm proposing would not 
>>> affect those who choose to add the prefix. It just accommodates those of us 
>>> who choose not to, thus expanding the audience of the framework.
>>> 
>>> Cheers,
>>> - hugi
>>> 
>>> 
>>> 
 On 26 Sep 2017, at 12:01, Michael Gentry  wrote:
 
 Hi Hugi,
 
 Let me try to sell you on the "get" prefix.  :-)
 
 (I did a lot of WebObjects/EOF in the past, in Objective-C and Java, so I
 understand the reluctance.)
 
 * The "get" prefix is part of the JavaBeans standard/contract.  With the
 exception of "is" for booleans (with a little "b").
 
 * There are tons of Java frameworks out there that expect and utilize the
 JavaBeans contract, so it is great for folding external frameworks into
 your code.  Or folding Cayenne into other frameworks, such as Tapestry.  I
 can specify Cayenne object/relationship paths in Tapestry (and other
 frameworks) such as
 t:value="currentItem.resourceSummary.grossCost.costs.continuingFootnote"
 (real example).  Since Tapestry expects the JavaBeans contract and Cayenne
 provides it, this works flawlessly.
 
 * In Eclipse (and others, I'm sure) I can do anObject.get[pause or
 control-space] and see all the getters associated with that object.
 Without the get prefix, they are spread out a-z and therefore you can't get
 as concise a list.
 
 mrg
 
 
 On Tue, Sep 26, 2017 at 7:02 AM, Hugi Thordarson  wrote:
 
> Hi all
> 
> Touching on an old subject that has now become more important with
> field-based Data Objects.
> 
> All of my DataObjects use accessor methods without the "get"-prefix. This
> was fine with Map Based data objects (where a MapAccessor would get
> property values by name), but now that my objects are field based, along
> comes BeanAccessor which is hardcoded to have every getter prefixed.
> 
> I propose that BeanAccessor be modified to allow accessor methods without
> the 

Re: Allowing property getters without a "get" prefix on DataObjects

[Andrus Adamchik]

Hi Maik,

In Cayenne a canonical way to override services is via DI. A PR that follows 
that approach has a good chance of acceptance. 

From a quick glance, I wonder if this new DI endpoint should be a factory of 
ClassDescriptorMap (which is currently lazily created inside EntityResolver). 
We can't make ClassDescriptorMap itself DI-managed as it depends on the mapping 
state, but a factory for it can be a DI singleton. Inside your custom factory 
(a few levels down actually) you can provide a subclass of BeanAccessor (maybe 
also via its own DI factory?).

Andrus


> On Sep 19, 2018, at 8:35 AM, Maik Musall  wrote:
> 
> Hi all,
> 
> I'd like to pull up this discussion from one year ago again. I'm currently 
> running 4.0 and testing upgrading to 4.1 using field-based DataObjects, and 
> I'm hitting the hard-coded prefixes in BeanAccessor that prevent me from 
> proceeding.
> 
> Yes, in theory I could sigh, yield, and use "get" prefixes, but not only do I 
> dislike introducing the "get" boilerplate everywhere. I am also somewhat 
> reluctant to make a refactoring touching some 800+ files in my project. To be 
> honest, I'd rather patch BeanAccessor to personal taste and deal with the 
> consequences.
> 
> BeanAccessor is currently always called by it's constructor. In addition to 
> the options Hugi described in his original mail in this thread, I could also 
> imagine a way to modify this to be able to inject a custom Accessor 
> implementation as an alternative. What do you think?
> 
> And… what would happen if someone would submit a pull request actually 
> implementing one of these options? :-)
> 
> Cheers
> Maik
> 
> 
>> Am 26.09.2017 um 15:32 schrieb Hugi Thordarson :
>> 
>> Hi Michael,
>> 
>> thanks for an honest attempt to convince me. Hard sell, though. :)
>> 
>> I use a lot of 3rd party libraries and I've only hit one time where using 
>> the bean spec was necessary — JasperReports. That was easily fixed by 
>> providing *BeanInfo classes, in accordance with the Bean spec. But Cayenne 
>> doesn't really follow the Java Bean Spec, it just hardcodes "is", "get" and 
>> "set".
>> 
>> As for the Eclipse thing… Well. A standard DataObject already has five 
>> methods prefixed with "get" so that list is questionable. And I don't miss 
>> this functionality.
>> 
>> I think it's important to note that the change I'm proposing would not 
>> affect those who choose to add the prefix. It just accommodates those of us 
>> who choose not to, thus expanding the audience of the framework.
>> 
>> Cheers,
>> - hugi
>> 
>> 
>> 
>>> On 26 Sep 2017, at 12:01, Michael Gentry  wrote:
>>> 
>>> Hi Hugi,
>>> 
>>> Let me try to sell you on the "get" prefix.  :-)
>>> 
>>> (I did a lot of WebObjects/EOF in the past, in Objective-C and Java, so I
>>> understand the reluctance.)
>>> 
>>> * The "get" prefix is part of the JavaBeans standard/contract.  With the
>>> exception of "is" for booleans (with a little "b").
>>> 
>>> * There are tons of Java frameworks out there that expect and utilize the
>>> JavaBeans contract, so it is great for folding external frameworks into
>>> your code.  Or folding Cayenne into other frameworks, such as Tapestry.  I
>>> can specify Cayenne object/relationship paths in Tapestry (and other
>>> frameworks) such as
>>> t:value="currentItem.resourceSummary.grossCost.costs.continuingFootnote"
>>> (real example).  Since Tapestry expects the JavaBeans contract and Cayenne
>>> provides it, this works flawlessly.
>>> 
>>> * In Eclipse (and others, I'm sure) I can do anObject.get[pause or
>>> control-space] and see all the getters associated with that object.
>>> Without the get prefix, they are spread out a-z and therefore you can't get
>>> as concise a list.
>>> 
>>> mrg
>>> 
>>> 
>>> On Tue, Sep 26, 2017 at 7:02 AM, Hugi Thordarson  wrote:
>>> 
 Hi all
 
 Touching on an old subject that has now become more important with
 field-based Data Objects.
 
 All of my DataObjects use accessor methods without the "get"-prefix. This
 was fine with Map Based data objects (where a MapAccessor would get
 property values by name), but now that my objects are field based, along
 comes BeanAccessor which is hardcoded to have every getter prefixed.
 
 I propose that BeanAccessor be modified to allow accessor methods without
 the "get"-prefix. Methods with "get" would get precedence, but if no method
 with a "get"-prefix exists, check for the existence of a method with only
 the property name.
 
 Although it's a minimal change in code, I realise it comes with a bit of
 potential baggage WRT testing. But this is not just to scratch a personal
 itch; once Cayenne 4.0 is out I want to start a large scale introduction of
 Cayenne to the EOF world where the get prefix is generally not liked and
 this change would have a big appeal. Besides, I'm not a big fan of the
 get-prefix myself, I find it a bit redundant :).
 
 An 

Re: Allowing property getters without a "get" prefix on DataObjects

[Maik Musall]

Hi all,

I'd like to pull up this discussion from one year ago again. I'm currently 
running 4.0 and testing upgrading to 4.1 using field-based DataObjects, and I'm 
hitting the hard-coded prefixes in BeanAccessor that prevent me from proceeding.

Yes, in theory I could sigh, yield, and use "get" prefixes, but not only do I 
dislike introducing the "get" boilerplate everywhere. I am also somewhat 
reluctant to make a refactoring touching some 800+ files in my project. To be 
honest, I'd rather patch BeanAccessor to personal taste and deal with the 
consequences.

BeanAccessor is currently always called by it's constructor. In addition to the 
options Hugi described in his original mail in this thread, I could also 
imagine a way to modify this to be able to inject a custom Accessor 
implementation as an alternative. What do you think?

And… what would happen if someone would submit a pull request actually 
implementing one of these options? :-)

Cheers
Maik


> Am 26.09.2017 um 15:32 schrieb Hugi Thordarson :
> 
> Hi Michael,
> 
> thanks for an honest attempt to convince me. Hard sell, though. :)
> 
> I use a lot of 3rd party libraries and I've only hit one time where using the 
> bean spec was necessary — JasperReports. That was easily fixed by providing 
> *BeanInfo classes, in accordance with the Bean spec. But Cayenne doesn't 
> really follow the Java Bean Spec, it just hardcodes "is", "get" and "set".
> 
> As for the Eclipse thing… Well. A standard DataObject already has five 
> methods prefixed with "get" so that list is questionable. And I don't miss 
> this functionality.
> 
> I think it's important to note that the change I'm proposing would not affect 
> those who choose to add the prefix. It just accommodates those of us who 
> choose not to, thus expanding the audience of the framework.
> 
> Cheers,
> - hugi
> 
> 
> 
>> On 26 Sep 2017, at 12:01, Michael Gentry  wrote:
>> 
>> Hi Hugi,
>> 
>> Let me try to sell you on the "get" prefix.  :-)
>> 
>> (I did a lot of WebObjects/EOF in the past, in Objective-C and Java, so I
>> understand the reluctance.)
>> 
>> * The "get" prefix is part of the JavaBeans standard/contract.  With the
>> exception of "is" for booleans (with a little "b").
>> 
>> * There are tons of Java frameworks out there that expect and utilize the
>> JavaBeans contract, so it is great for folding external frameworks into
>> your code.  Or folding Cayenne into other frameworks, such as Tapestry.  I
>> can specify Cayenne object/relationship paths in Tapestry (and other
>> frameworks) such as
>> t:value="currentItem.resourceSummary.grossCost.costs.continuingFootnote"
>> (real example).  Since Tapestry expects the JavaBeans contract and Cayenne
>> provides it, this works flawlessly.
>> 
>> * In Eclipse (and others, I'm sure) I can do anObject.get[pause or
>> control-space] and see all the getters associated with that object.
>> Without the get prefix, they are spread out a-z and therefore you can't get
>> as concise a list.
>> 
>> mrg
>> 
>> 
>> On Tue, Sep 26, 2017 at 7:02 AM, Hugi Thordarson  wrote:
>> 
>>> Hi all
>>> 
>>> Touching on an old subject that has now become more important with
>>> field-based Data Objects.
>>> 
>>> All of my DataObjects use accessor methods without the "get"-prefix. This
>>> was fine with Map Based data objects (where a MapAccessor would get
>>> property values by name), but now that my objects are field based, along
>>> comes BeanAccessor which is hardcoded to have every getter prefixed.
>>> 
>>> I propose that BeanAccessor be modified to allow accessor methods without
>>> the "get"-prefix. Methods with "get" would get precedence, but if no method
>>> with a "get"-prefix exists, check for the existence of a method with only
>>> the property name.
>>> 
>>> Although it's a minimal change in code, I realise it comes with a bit of
>>> potential baggage WRT testing. But this is not just to scratch a personal
>>> itch; once Cayenne 4.0 is out I want to start a large scale introduction of
>>> Cayenne to the EOF world where the get prefix is generally not liked and
>>> this change would have a big appeal. Besides, I'm not a big fan of the
>>> get-prefix myself, I find it a bit redundant :).
>>> 
>>> An alternative would be to adhere to the Bean standard, and make
>>> BeanAccessor read bean meta information (usually specified in *BeanInfo
>>> classes) and get names of getter/setter methods from there. But that would
>>> be a much larger change than just checking for a method with propertyName
>>> if the getPropertyName method doesn't exist.
>>> 
>>> What do you think?
>>> 
>>> Cheers,
>>> - hugi
> 

Re: Allowing property getters without a "get" prefix on DataObjects

[Musall, Maik]

+1 :-)

> Am 26.09.2017 um 15:32 schrieb Hugi Thordarson :
> 
> Hi Michael,
> 
> thanks for an honest attempt to convince me. Hard sell, though. :)
> 
> I use a lot of 3rd party libraries and I've only hit one time where using the 
> bean spec was necessary — JasperReports. That was easily fixed by providing 
> *BeanInfo classes, in accordance with the Bean spec. But Cayenne doesn't 
> really follow the Java Bean Spec, it just hardcodes "is", "get" and "set".
> 
> As for the Eclipse thing… Well. A standard DataObject already has five 
> methods prefixed with "get" so that list is questionable. And I don't miss 
> this functionality.
> 
> I think it's important to note that the change I'm proposing would not affect 
> those who choose to add the prefix. It just accommodates those of us who 
> choose not to, thus expanding the audience of the framework.
> 
> Cheers,
> - hugi
> 
> 
> 
>> On 26 Sep 2017, at 12:01, Michael Gentry  wrote:
>> 
>> Hi Hugi,
>> 
>> Let me try to sell you on the "get" prefix.  :-)
>> 
>> (I did a lot of WebObjects/EOF in the past, in Objective-C and Java, so I
>> understand the reluctance.)
>> 
>> * The "get" prefix is part of the JavaBeans standard/contract.  With the
>> exception of "is" for booleans (with a little "b").
>> 
>> * There are tons of Java frameworks out there that expect and utilize the
>> JavaBeans contract, so it is great for folding external frameworks into
>> your code.  Or folding Cayenne into other frameworks, such as Tapestry.  I
>> can specify Cayenne object/relationship paths in Tapestry (and other
>> frameworks) such as
>> t:value="currentItem.resourceSummary.grossCost.costs.continuingFootnote"
>> (real example).  Since Tapestry expects the JavaBeans contract and Cayenne
>> provides it, this works flawlessly.
>> 
>> * In Eclipse (and others, I'm sure) I can do anObject.get[pause or
>> control-space] and see all the getters associated with that object.
>> Without the get prefix, they are spread out a-z and therefore you can't get
>> as concise a list.
>> 
>> mrg
>> 
>> 
>> On Tue, Sep 26, 2017 at 7:02 AM, Hugi Thordarson  wrote:
>> 
>>> Hi all
>>> 
>>> Touching on an old subject that has now become more important with
>>> field-based Data Objects.
>>> 
>>> All of my DataObjects use accessor methods without the "get"-prefix. This
>>> was fine with Map Based data objects (where a MapAccessor would get
>>> property values by name), but now that my objects are field based, along
>>> comes BeanAccessor which is hardcoded to have every getter prefixed.
>>> 
>>> I propose that BeanAccessor be modified to allow accessor methods without
>>> the "get"-prefix. Methods with "get" would get precedence, but if no method
>>> with a "get"-prefix exists, check for the existence of a method with only
>>> the property name.
>>> 
>>> Although it's a minimal change in code, I realise it comes with a bit of
>>> potential baggage WRT testing. But this is not just to scratch a personal
>>> itch; once Cayenne 4.0 is out I want to start a large scale introduction of
>>> Cayenne to the EOF world where the get prefix is generally not liked and
>>> this change would have a big appeal. Besides, I'm not a big fan of the
>>> get-prefix myself, I find it a bit redundant :).
>>> 
>>> An alternative would be to adhere to the Bean standard, and make
>>> BeanAccessor read bean meta information (usually specified in *BeanInfo
>>> classes) and get names of getter/setter methods from there. But that would
>>> be a much larger change than just checking for a method with propertyName
>>> if the getPropertyName method doesn't exist.
>>> 
>>> What do you think?
>>> 
>>> Cheers,
>>> - hugi
> 

Re: Allowing property getters without a "get" prefix on DataObjects

[Michael Gentry]

Hi Hugi,

Let me try to sell you on the "get" prefix.  :-)

(I did a lot of WebObjects/EOF in the past, in Objective-C and Java, so I
understand the reluctance.)

* The "get" prefix is part of the JavaBeans standard/contract.  With the
exception of "is" for booleans (with a little "b").

* There are tons of Java frameworks out there that expect and utilize the
JavaBeans contract, so it is great for folding external frameworks into
your code.  Or folding Cayenne into other frameworks, such as Tapestry.  I
can specify Cayenne object/relationship paths in Tapestry (and other
frameworks) such as
t:value="currentItem.resourceSummary.grossCost.costs.continuingFootnote"
(real example).  Since Tapestry expects the JavaBeans contract and Cayenne
provides it, this works flawlessly.

* In Eclipse (and others, I'm sure) I can do anObject.get[pause or
control-space] and see all the getters associated with that object.
Without the get prefix, they are spread out a-z and therefore you can't get
as concise a list.

mrg


On Tue, Sep 26, 2017 at 7:02 AM, Hugi Thordarson  wrote:

> Hi all
>
> Touching on an old subject that has now become more important with
> field-based Data Objects.
>
> All of my DataObjects use accessor methods without the "get"-prefix. This
> was fine with Map Based data objects (where a MapAccessor would get
> property values by name), but now that my objects are field based, along
> comes BeanAccessor which is hardcoded to have every getter prefixed.
>
> I propose that BeanAccessor be modified to allow accessor methods without
> the "get"-prefix. Methods with "get" would get precedence, but if no method
> with a "get"-prefix exists, check for the existence of a method with only
> the property name.
>
> Although it's a minimal change in code, I realise it comes with a bit of
> potential baggage WRT testing. But this is not just to scratch a personal
> itch; once Cayenne 4.0 is out I want to start a large scale introduction of
> Cayenne to the EOF world where the get prefix is generally not liked and
> this change would have a big appeal. Besides, I'm not a big fan of the
> get-prefix myself, I find it a bit redundant :).
>
> An alternative would be to adhere to the Bean standard, and make
> BeanAccessor read bean meta information (usually specified in *BeanInfo
> classes) and get names of getter/setter methods from there. But that would
> be a much larger change than just checking for a method with propertyName
> if the getPropertyName method doesn't exist.
>
> What do you think?
>
> Cheers,
> - hugi