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
On 11 November 2017 at 21:56, Eagle Offshore 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 differe
> On Nov 9, 2017, at 10:00 AM, Itai Ferber wrote:
>
> Hi Brent,
>
> Perhaps the wording would be better phrased as "boundary from
> non-uppercase-character to uppercase-character", i.e. numbers and Emoji are
> treated the same as lowercase characters and are included in the original
> word.
>
I’m a fan. I understand that the CodingKey was the initial thought behind how
to customise this, but a transformative approach is nice where there is a
patterned update to keys.
Just one question: is there much performance impact by running through a key
encoding strategy, even if it’s just a r
Hi Brent,
Perhaps the wording would be better phrased as "boundary from
non-uppercase-character to uppercase-character", i.e. numbers and Emoji
are treated the same as lowercase characters and are included in the
original word.
The following are [unit test cases from the associated
PR](https:
> On Nov 6, 2017, at 12:54 PM, Tony Parker via swift-evolution
> wrote:
>
> Converting from camel case to snake case:
>
> 1. Splits words at the boundary of lower-case to upper-case
> 2. Inserts `_` between words
> 3. Lowercases the entire string
> 4. Preserves starting and ending `_`.
>
> For
Hi Itai,
I see. I thought that the second reason you mentioned is so reasonable.
Apart from this proposal, if enum with String as RawValue is defined by
omitting StringLiteral, it would be a good idea to have a mechanism to
generate snake_case or a space delimited string.
2017-11-08 2:20 GMT+09:
+1. Would allow me to delete a ton of code in my current project.
> On Nov 6, 2017, at 2:54 PM, Tony Parker via swift-evolution
> 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
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 handl
But the transformation of the string representation of keys is a feature which
other coders/decoders could use, so it might be worth pulling it out of the
JSONDecoder/JSONEncoder namespace and make the implementation callable. For
example, I could imagine wanting to use a similar system with pro
Hi Norio,
There are two reasons that I think this is valuable over doing something
in `CodingKeys`:
1. The definition you give your coding keys affects all encoding
formats. JSON is a format where snake_case can be relatively common, so
the transformation makes a lot of sense there. For othe
Yeha the API surface is a good concern. I was wondering if it would make sense
to be part of String for example instead of tying it to the encoders api. I
guess add that point it will be a different discussion.
In any case, good proposal ;)
Sent from my iPad
> On 7 Nov 2017, at 00:35, Tony Park
Hi Tony,
Is it better for us to choose on `Codable` side whether `rawValue` of
`CodingKeys` should be generated with snake_case?
It seems to be more consistent with the current method of setting
`rawValue` of `CodingKeys` on `Codable` side.
Thanks,
--
@norio_nomura
2017-11-07 5:54 GMT+09:00 Tony
Hi Alejandro,
> On Nov 6, 2017, at 3:14 PM, Alejandro Martinez via swift-evolution
> wrote:
>
> I’m in favor of this as it’s really, but specially the custom strategy. And
> thinking about that, would there be a way to expose the functionality of
> converting a string to camel case or snake c
I’m in favor of this as it’s really, but specially the custom strategy. And
thinking about that, would there be a way to expose the functionality of
converting a string to camel case or snake case so it could be used in case of
writing a custom strategy. Would be cool to have the original functi
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
16 matches
Mail list logo
