cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugi Thordarson <h...@karlmenn.is>
Subject Re: Allowing property getters without a "get" prefix on DataObjects
Date Tue, 25 Sep 2018 13:59:57 GMT
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
<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 <andrus@objectstyle.org> 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 <hugi@karlmenn.is> 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 <andrus@objectstyle.org> 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 <maik@selbstdenker.ag> 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 <hugi@karlmenn.is>:
>>>>> 
>>>>> 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 <blacknext@gmail.com>
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 <hugi@karlmenn.is>
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
>>>>> 
>>>> 
>>> 
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message