drkibitz
commented
5 years ago The same goes for Swift and let vs var properties. Although I've been using QuickType a while, and realize it focuses on a the schema side of a model, rather than the stateful side. e.g. Immutability vs mutable. That said, I haven't had a need for var, with the helpers provided to Swift such as the o.with(...) method.
Off topic a bit, we did end up writing a couple plugins to make things easier, one of those being factories of defaultsForNil, and defaultsForNull (for Kotlin respectively). This is because it's very inconvenient to always specify defaults when your models become quite large. These helpers provide all params as nil or null, and use a default if left that way. It was done this way, because at least at the time of writing the plugins, it wasn't easy or even possible to modify the output of initializers/constructors that QuickType generates.
Back on topic... although we haven't needed mutable models, it would be a great feature for Swift, as it would cut out some boilerplate in a lot of circumstances. This feature could work at least with both TypeScript or json-schema as sources if "readOnly" properties were observed. Probably not all sources, though even for graphql might be possible with custom annotations.
I don't know if this can be considered a general issue but, for me, the fact that all the properties in a kotlin class are generated as val instead of var creates some problems for me. I've identified that line 336 in src/quicktype-core/language/Kotlin.ts always emits val so, I guess, is not language or "source syntax" dependent. To create a little bit of context, what I've created is a small project where I can write typescript interfaces (because I am using ts on my backend) and using a single CLI command, a kotlin file (and in the future swift file) with all the data classes definitions is created and published as a library in a private maven repository. This is useful because we are using Firebase and it's more convenient to have the data models as a library for each platform (Android, iOS, and backend) instead of using other channels to communicate the data model changes. In the Firebase Docs data classes are using var. I'm new to Kotlin but having the properties as var also makes sense for me, because I want to be able to get (and create objects) and set the values not just get.
Can this be considered a general issue or am I missing anything about quicktype or kotlin?