JSONEncoder: Key strategies

a big fat -1. sorry.

imho, this is barking up the wrong tree and things like converting from
camel case / snake case / removal underscores/ capitalization / etc, etc
shall not be part of foundation. even if people in the labs asking for
that. third party library - probably.

more easy way to handle keys customization would be nice, last i checked it
was "all or nothing", whenever i wanted to customise a single key i had to
do them all and the source tripled in size. something simple to avoid that
would be enough, imho.

Mike

···

on Mon, 06 Nov 2017 12:54:38 -0800 Tony Parker <anthony.parker@apple.com> wrote:

Hi everyone,

While we have no formal process at this time for proposals of changes to
Foundation-only code, I would still like to post one that we have run
through our internal process here for additional public comment.

Link to PR with proposal content:

https://github.com/apple/swift-corelibs-foundation/pull/1301

Link to implementation for the overlay:

https://github.com/apple/swift/pull/12779 <https://github.com/apple/swif
t/pull/12779>

Markdown follows.

Thanks,
- Tony

# Key Strategies for JSONEncoder and JSONDecoder

* Proposal: SCLF-0001
* Author(s): Tony Parker <anthony.parker@apple.com>

##### Related radars or Swift bugs

* <rdar://problem/33019707> Snake case / Camel case conversions for
JSONEncoder/Decoder

##### Revision history

* **v1** Initial version

## Introduction

While early feedback for `JSONEncoder` and `JSONDecoder` has been very
positive, many developers have told us that they would appreciate a
convenience for converting between `snake_case_keys` and `camelCaseKeys`
without having to manually specify the key values for all types

.....

I have to agree, would be better to allow one to provide a mapping dictionary or delegate. Building the encodingKeys into the class itself is short sighted and a half measure.

Different types of codings will necessarily desire different key sets and even different names for what are logically the same keys. This absolutely should NOT be baked into the class that implements Codable but rather maybe a delegate that is presented each key/value and given an opportunity to provide a substitute key and value.

Codable is a fairly useless one trick pony in its current incarnation. It doesn't really solve any problem I have with respect to interacting with web services.

···

On Nov 7, 2017, at 2:50 PM, Mike Kluev via swift-evolution <swift-evolution@swift.org> wrote:

a big fat -1. sorry.

imho, this is barking up the wrong tree and things like converting from camel case / snake case / removal underscores/ capitalization / etc, etc shall not be part of foundation. even if people in the labs asking for that. third party library - probably.

more easy way to handle keys customization would be nice, last i checked it was "all or nothing", whenever i wanted to customise a single key i had to do them all and the source tripled in size. something simple to avoid that would be enough, imho.

Mike

on Mon, 06 Nov 2017 12:54:38 -0800 Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> wrote:

Hi everyone,

While we have no formal process at this time for proposals of changes to Foundation-only code, I would still like to post one that we have run through our internal process here for additional public comment.

Link to PR with proposal content:

https://github.com/apple/swift-corelibs-foundation/pull/1301

Link to implementation for the overlay:

https://github.com/apple/swift/pull/12779 <https://github.com/apple/swift/pull/12779>

Markdown follows.

Thanks,
- Tony

# Key Strategies for JSONEncoder and JSONDecoder

* Proposal: SCLF-0001
* Author(s): Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>>

##### Related radars or Swift bugs

* <rdar://problem/33019707> Snake case / Camel case conversions for JSONEncoder/Decoder

##### Revision history

* **v1** Initial version

## Introduction

While early feedback for `JSONEncoder` and `JSONDecoder` has been very positive, many developers have told us that they would appreciate a convenience for converting between `snake_case_keys` and `camelCaseKeys` without having to manually specify the key values for all types
.....

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

in defence of Codable, my experience so far told me:

- it is very useful

- easy to use especially when you can change those structures / keys, e.g.
when you have an influence on the service side as well, or the service side
is designed at the same time - when you start from clean state in other
words.

- even if you need to talk to an already established service - the key's
translation it's doable now (could have been easier though)

- it is very logical to hook the logic of the key translation in the
Codable subclass itself (maybe in a different form to what it is now)
rather than do it externally - the latter is a more "manual" and thus a
more error prone approach where things can be easily screwed.

- the ideal design (not current) would allow to do the translation the way
you want (e.g. via the delegate). so shall be win-win.

Mike

···

On 11 November 2017 at 21:56, Eagle Offshore <eagleoffshore@me.com> wrote:

I have to agree, would be better to allow one to provide a mapping
dictionary or delegate. Building the encodingKeys into the class itself is
short sighted and a half measure.

Different types of codings will necessarily desire different key sets and
even different names for what are logically the same keys. This absolutely
should NOT be baked into the class that implements Codable but rather maybe
a delegate that is presented each key/value and given an opportunity to
provide a substitute key and value.

Codable is a fairly useless one trick pony in its current incarnation. It
doesn't really solve any problem I have with respect to interacting with
web services.