Comments (15)
You're usually following Java's conventions in other areas of your code, so for an other reader (or yourself after a few months not looking at the code), it's extremely confusing to see two conventions used inside one codebase. Hence the unique convention.
from moshi.
I have to agree with @mehdibaha here. I'll add that forcing a 1:1 naming relationship might work great when you're controlling both the API and the Client. However, my company routinely integrates with multiple third parities in the same project. It seems like a silly constraint to be forced to use whatever arbitrary naming policy the third party is using. And two different conventions can turn to 10 very quickly.
And @swankjesse: Strictly following Java's conventions may be unnecessary in your circumstance, but in mine, my engineering department uses a well defined set of coding standards. And the argument that we'd have to change them in some circumstances because our favorite resource for quality libraries (that's you guys) says it's unnecessary isn't going to cut it.
Sure, one could argue that there are myriad libraries for JSON serialization/deserialization, and that we should go with one of those. Sure. But there's a reason we look to you guys. And that's the same reason others will keep piping in to request this feature. Just a prediction.
from moshi.
How about making this equivalent to Gson @JsonAdapter annotation?
The developer should be able to specify arbitrary type adapter for a field and class.
from moshi.
Moshi looks up type adapters by type + annotation. So you can do @UnixEpoch long authenticatedAt
and register the corresponding adapter in Moshi. I'm slightly reluctant to support @JsonAdapter
, but I can be convinced!
from moshi.
The biggest benefit of JsonAdapter (from my perspective) is that it allows me to specify the custom type adapter for my class without requiring the Gson instance to register it.
In Moshi, how do you propose to automatically register a custom type adapter for a type?
from moshi.
The closest we'll come to automatic JSON binding is this: #29
from moshi.
that works, and also takes care of subclasses
from moshi.
@JsonName
? Not that I don't like @Json
or anything.
from moshi.
Would it be dual-purpose? @Json(value="foo", adapter=FooJsonAdapter.class)
?
from moshi.
can you please explain why you don't want a general field name policy support?
since most of the json is generated from python/ruby field naming conventions, and the policy itself is just a String -> String
function
does this have to do to the efficient okio-based nature of moshi? (but then again @Json
will be supported somehow)
from moshi.
We don't support field naming policy because it breaks grep. Programming becomes a lot easier once you commit to not breaking grep.
(If you see a field like shipping_address
in your JSON, you can search for that in your code and find it.)
from moshi.
Hi,
I'm sorry but I need to ask this question (since it's the only reason why I haven't adopted moshi yet) :
Who need to grep his code for a particular field name only found (normally) in the server code.
When you arrive at the client code, all the field naming conventions change, and you can start grepping for ShippingAdress, so I don't see how that's a reason for you not implementing yet policy-based name mangling.
from moshi.
@mehdibaha strictly following Java's conventions is unnecessary. You make the whole thing simpler by just using the same names on client and server.
from moshi.
from moshi.
I think you've made the right choice. Thanks.
from moshi.
Related Issues (20)
- Type mismatch: inferred type is Buffer but BufferedSink! was expected
- Parse double to string; Uncontrollable accuracy
- KSP2 error "Packages cannot be imported" HOT 2
- 速度这块 没有gson 自动生成的插件快 https://github.com/NBXXF/gson_plugin
- Is it possible to fail build when KSP is not configured but @JsonClass(generateAdapter = true) is used?
- warning: Kapt support in Moshi Kotlin Code Gen is deprecated and will be removed in 2.0. HOT 3
- Backend Internal error: Exception during IR lowering HOT 1
- Update Okio to 3.4.0 or higher HOT 4
- Field serialized despite of the Transient annotation
- Kotlin Duration Adapter fails to be generated with codegen
- Undocumented behavior on serialization of non-constructor property with defaults HOT 12
- Better egonomics when replacing nulls with default values HOT 4
- Alternative Enum adapter with default value HOT 8
- Retrofit / enum class / @Json name specified / @FormUrlEncoded API HOT 1
- Bug with ProGuard and R8 HOT 3
- Out of memory error HOT 2
- Support Kotlin Multiplatform HOT 2
- Classes annotated with @JsonClass(generateAdapter = true) are not obfuscated HOT 1
- Moshi Codegen doesn't work with OpenAPI 3.1.0 HOT 7
- `@JsonClass(generateAdapter = true)` fails when class has field with type `Array<Array<T>>` with default
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from moshi.