The design decision for why you use setFieldNamingPolicy and pass an
enum is beyond me. How do I pass a custom naming policy? Why have
you set it up to pass an enum instead of an interface?
It seems to me, the correct way of implementing this would be to make
setFieldNamingStrategy public, along with the matching interface, so I
can easily customize the naming policy/strategy.
It is open source so I can build it myself with the above changes, but
I am curios as to why it was made this way?
The primary reason we did it that way is because we did not want to
complicate the API.
Moreover, the naming policy is a tricky thing to get right since the
output must be valid JSON as well as Java. What policy are you looking
for specifically? May be you can present an example of where the
custom policy will be useful.
In my code I use the convention of m_varName for member variables. I would
like a policy that removes the m_ from the variable name. Very simple
really. And I'm also only concerned with java to json, but it would be
pretty easy to match varName to m_varName.
I understand the desire to not complicate the API, but restricting
functionality only hinders adoption of your code. Besides any complicated
API can be simplified via good documentation, which you have done pretty
well at.
Brian
On Fri, Jan 9, 2009 at 10:37 AM, inder...@gmail.com <inder...@gmail.com>wrote:
> The primary reason we did it that way is because we did not want to
> complicate the API.
> Moreover, the naming policy is a tricky thing to get right since the
> output must be valid JSON as well as Java. What policy are you looking
> for specifically? May be you can present an example of where the
> custom policy will be useful.
On Fri, Jan 9, 2009 at 12:23 PM, Brian Hawkins <brianh...@gmail.com> wrote:
> In my code I use the convention of m_varName for member variables. I would
> like a policy that removes the m_ from the variable name. Very simple
> really. And I'm also only concerned with java to json, but it would be
> pretty easy to match varName to m_varName.
> I understand the desire to not complicate the API, but restricting
> functionality only hinders adoption of your code. Besides any complicated
> API can be simplified via good documentation, which you have done pretty
> well at.
> Brian
> On Fri, Jan 9, 2009 at 10:37 AM, inder...@gmail.com <inder...@gmail.com>wrote:
>> The primary reason we did it that way is because we did not want to
>> complicate the API.
>> Moreover, the naming policy is a tricky thing to get right since the
>> output must be valid JSON as well as Java. What policy are you looking
>> for specifically? May be you can present an example of where the
>> custom policy will be useful.
On Fri, Jan 9, 2009 at 12:14 PM, Jacob Tomaw <jacob.to...@gmail.com> wrote:
> Does the SerializedName annotation solve this?
> Jacob
> On Fri, Jan 9, 2009 at 12:23 PM, Brian Hawkins <brianh...@gmail.com>wrote:
>> In my code I use the convention of m_varName for member variables. I
>> would like a policy that removes the m_ from the variable name. Very simple
>> really. And I'm also only concerned with java to json, but it would be
>> pretty easy to match varName to m_varName.
>> I understand the desire to not complicate the API, but restricting
>> functionality only hinders adoption of your code. Besides any complicated
>> API can be simplified via good documentation, which you have done pretty
>> well at.
>> Brian
>> On Fri, Jan 9, 2009 at 10:37 AM, inder...@gmail.com <inder...@gmail.com>wrote:
>>> The primary reason we did it that way is because we did not want to
>>> complicate the API.
>>> Moreover, the naming policy is a tricky thing to get right since the
>>> output must be valid JSON as well as Java. What policy are you looking
>>> for specifically? May be you can present an example of where the
>>> custom policy will be useful.
Just to set some expectations: we are very close to release a version
of Gson 1.3 (probably beta) and would not like to add any more feature
at this time. However, we will start a discussion on the design of
this feature to get some feedback from the group before finalizing
it.
So, in the short term you have the option of modifying Gson's source-
code or following Jacob's suggestion.
|
