Re: [swift-evolution] Add transformers to Codable
For me definitely +1 as it's getting near to what I need to call the Decoding
usable.
> On Dec 18, 2017, at 5:51 PM, Arsen Gasparyan via swift-evolution
> wrote:
>
> Hello everyone,
>
> I’m suggesting to add a new way to encode/decode JSON properties for
> relevantly complex data formats such as regular expressions, well-known text,
> hex colours, custom date formats.
>
> The problem:
>
> Image you have a struct called House
>
> struct House {
> let color: UIColor
> }
>
> and it has a properly called color and the color represented in JSON as hex
> value (#ff). Currently to make it working you have to extract the
> underline value (string with a hex value) and then try to make a UIColor from
> it. It works but it makes you to copy/past a lot of code and it leads to
> problems. Also it shifts focus from what to decode to how to decode.
>
> The suggested solution:
>
> I suggest that we have to introduce protocols for classes that will
> encapsulate transformation from a source data type to a destination data
> type. The source data types are all existing data that support of decoding.
>
> We will provide only protocols (one for decoding and one for encoding) and
> users will be able to create transformers for their own data types.
>
> The implementation:
>
> The implementation is fairly easy. We only need introduce two protocols
> (encoding/decoding) and add a method to KeyedEncodingContainerProtocol that
> will accept a key and a transformer. In the method we will extract source
> data from JSON and then will ask the transformer to try to convert it to the
> desire data type.
>
> Example of the decoding protocol:
>
> protocol DecodingTransformer {
> associatedtype Input: Decodable
> associatedtype Output
> func transform(_ decoded: Input) throws -> Output
> }
>
>
> Inspired by: https://github.com/Hearst-DD/ObjectMapper#custom-transforms
>
>
> Cheers,
> Arsen
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] Add transformers to Codable
Hello everyone,
I’m suggesting to add a new way to encode/decode JSON properties for relevantly
complex data formats such as regular expressions, well-known text, hex colours,
custom date formats.
The problem:
Image you have a struct called House
struct House {
let color: UIColor
}
and it has a properly called color and the color represented in JSON as hex
value (#ff). Currently to make it working you have to extract the underline
value (string with a hex value) and then try to make a UIColor from it. It
works but it makes you to copy/past a lot of code and it leads to problems.
Also it shifts focus from what to decode to how to decode.
The suggested solution:
I suggest that we have to introduce protocols for classes that will encapsulate
transformation from a source data type to a destination data type. The source
data types are all existing data that support of decoding.
We will provide only protocols (one for decoding and one for encoding) and
users will be able to create transformers for their own data types.
The implementation:
The implementation is fairly easy. We only need introduce two protocols
(encoding/decoding) and add a method to KeyedEncodingContainerProtocol that
will accept a key and a transformer. In the method we will extract source data
from JSON and then will ask the transformer to try to convert it to the desire
data type.
Example of the decoding protocol:
protocol DecodingTransformer {
associatedtype Input: Decodable
associatedtype Output
func transform(_ decoded: Input) throws -> Output
}
Inspired by: https://github.com/Hearst-DD/ObjectMapper#custom-transforms
Cheers,
Arsen___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Optional Argument Chaining
+1 -Thorsten > Am 18.12.2017 um 08:42 schrieb Elviro Rocca via swift-evolution > : > > While it's definitely worth knowing, it's not a really usable substitute for > higher-kinded types in production code, and still requires a lot of code > generation, which is eased in Kotlin thanks to its annotation/metaprogramming > features. > > Event the Kategory people recognized that the emulation approach is a > temporary solution, waiting for the approval of a proposal for the addition > of HKTs to Kotlin itself. > > Unfortunately, if we don't get HKTs in Swift we're simply going to miss on a > barrage of extremely useful abstractions, upon that many contemporary > languages have started to rely, because they are simply the best known > solutions to many problems in many contexts. > > The huge amount of work that's been done in academia in the last 15 years > (and it's still going) about applicatives - and also profunctor optics, > another thing that requires HKTs - is mostly going to elude Swift due to its > crucial lack of expressivity. > > We're on the right track with the approval of the conditional conformance > proposal, but my fear is that the ABI stability requirement for Swift 5 is > going to lock the language interfaces in a state where it's going to be > impossible for these kinds of sophistications to be added to the language at > a later stage... I hope to be proven wrong here. > > > Elviro > >> Il giorno 14 dic 2017, alle ore 15:40, Matthew Johnson via swift-evolution >> ha scritto: >> >> >> Thanks for jumping in and elaborating on a more general approach! I don’t >> want to sidetrack the thread, but it actually is possible to encode >> higher-kindred types and protocols requiring them in Swift today. It’s a >> bit clunky and requires some boilerplate but the technique is worth knowing. >> https://gist.github.com/anandabits/f12a77c49fc002cf68a5f1f62a0ac9c4 >> >> Some Kotlin folks have created a pretty robust FP library using the same >> technique: http://kategory.io/. >> >> ___ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > ___ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
