Poll: Change method names to Java Bean Accessor Syntax

[dkunzler]

After seeing the discussion in #62 I think about adding the required naming scheme as additional possibility or changing the syntax completely in a new release.

So this poll is about: a) add the possibility to use set and get additionally to the current method names where only the parameter determine the set/get operation. b) completely remove support for access via only method names and completely change it to set/get

Pros/Cons for the set/get naming scheme:

• (+) compliant to Java Bean Naming Convention and therefore better compatibility with potential other technologies like Kotlin
• (+) more visible distinction between getter and setter
• (-/+) getters with runtime defaults do not necessarily need a prefix and therefore a different name (getProperty(String default) would work whereas now it is property$Default(String default))
• (-) extreme breaking API change
• (-) understanding what the actual name of the preference will be is quite harder. (take the case into account: setProperty would still save into property not Property)

Apologize for tagging you people, but you are the only ones I know that use the library, so to get feedback I specifically ask: @danielneu @mflisar @dmo60 @rguthor2 @anthony3444 @naixx @asadkt Hopefully you are not mad about this :D

Thanks in Advance for feedback

[MFlisar]

Before I answer, did you ever think about moving this library on to kotlin? This may open up new possibilities and even some things can be done without annotation processing...

[dkunzler]

No, apart from the basic Syntax I'm not that familiar with advanced kotlin features. Do you have more insight on what of this lib can be done in kotlin without annotation processing?

[MFlisar]

You can check out this library: https://github.com/chibatching/Kotpref namely it's mostly kotlin delegates you can use to set/get values. For many use cases the linked library may be already a full kotlin alternative to your library - your library has some special features I use that make me still prefer your library.

If you move your library to kotlin and use fields for preference values, the getter/setter problem in java will be solved automatically as well as a simple side effect.

[dmo60]

(-) extreme breaking API change

Supporting both the old and the getter/setter syntax would probably be the less intrusive change. But it comes with a slight cost of decreased ease of use (one more feature to explain, one more decision to take).

(-) understanding what the actual name of the preference will be is quite harder. (take the case into account: setProperty would still save into property not Property)

It's probably a bad idea to guess and hardcode the name of the property anyways. For the use-case where the actual key name is required, you could advertise the key-gen processor.

[MFlisar]

I'll give you my point of view:

• I personally don't mind if you make such a change - I would not make it backwards compatible. I would say your recent releases (over years) mostly did not fix any issues but added some features (some requested by me), so I would just create a v2 branch and make the changes there as the current branch can be used in the future as well if someone wants to stick to it.
• I prefer the kotlin way of distinction between getters/setters, so I would like this change
• as I said, I personally would even migrate to kotlin (which has a few side effects that probably makes things easier but is also more work of course)

To your points, I totally agree with them. And my personal decision in your situation would be to go the clean way and abandon the old method names and introduce the new ones.

Additionally, I would suggest respecting the new incremental annotations as well.

[dkunzler]

Thanks for all your feedback. I will make a new major version with changed naming in the future. Stay tuned. This also affect #62