Swift 4 - Decodable/Encodable protocols

[ferusinfo]

New Swift 4 will include a new encoding/decoding protocols (https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md)

Since Gloss is sharing the same namespace for protocols Decodable/Encodable, I suggest we change the name of the protocols, so Gloss can be a separate library to the new solution proposed by the Swift language team.

@hkellaway - thoughts?

[hkellaway]

yeah - i saw that and was thinking similarly 😑 perhaps JSONDecodable and JSONEncodable.

i'll create a swift_4.0 branch for if you or any of the WWDCers feel inspired to get tinkering

[ejmartin504]

Since Swift has module namespacing, for now Gloss is usable in XCode 9 by simply prepending "Gloss." to all use of Decodable and Encodable. Probably not an ideal solution long term though!

[ryanschneider]

Have you considered making a Gloss 2.0 which builds on top of the Swift 4 primitives?

I haven't dug in deeply, but I feel like these spots can be much more ergonomically handled by a 3rd party library like Gloss than what's in Swift 4:

• custom date encoding/decoding. Personally I have Glossy structs that have Date fields that need to use different DateFormatters (e.g. for legacy reasons some fields are UTC, some ISO8601, and others just MM/DD/YYYY). Swift.Codable requires me to set the encoder/decoders date decoding to custom, and then inspect the CodingKey keyPath to decide on the DateFormatter to use (since I can't use the same DateFormatter for all of the fields)

• custom encode/decode functions: Personal choice, but I prefer Gloss' ~~> and <~~ to the try-heavy approach used in init(from decoder: Decoder) and func encode(to encoder: Encoder).

I feel like there's room for a "DSL" over Codable that combines the CodingKey concept (which is great!) with Gloss' ergonomics (which is even greater!).

Even a Gloss 1.x that adds support for CodingKeys for the JSON keys would be awesome (no more duplicating key name strings in toJSON and `init1!).

[hkellaway]

Neat ideas! Though I had not considered a re-write on top of Swift JSON parsing. I was simply going to update for compatibility. I was more viewing this an opportunity to eventually halt feature development as native JSON parsing gains popularity. I don't have the bandwidth to personally support Gloss indefinitely.

I agree there's room for a DSL on top of Swift's and others are free to take that notion and other ones present in Gloss and run with it.

[lastcc]

@hkellaway according to the doc, we have to write 2 separate methods to support transform and reverse transform, but ObjectMapper requires only one.

I know if we use 2 methods there are certain benefits, but can I only write one?
--------------------------------
If you use carthage the display names in the terminal output have some issues:
*** Building scheme "Gloss" in Gloss.xcodeproj
*** Building scheme "Gloss MacOS" in Gloss.xcodeproj

i think we can change it to be Gloss iOS and Gloss macOS

[hkellaway]

@lastcc im interpreting this as 2 separate questions

1. im not familiar with ObjectMapper - taking a quick look at their docs, maybe you're talking about their TransformOf syntax? no, there is not an equivalent in Gloss
2. true, the naming of the framework targets could be more precise as you describe

[ergunkocak]

Is it possible to start a new version string for swift 4 branch like 1.4.x and release on Cocoapods?
I know we can use with branch parameter in cocoapods but to be able to use in podspec file of my private pod i need a seperate version. AFAIS pod version is same in "swift_4.0" branch as "master"

[hkellaway]

@ergunkocak swift_4.0 is currently the same as master so you can point to 1.2.4 in your private spec. once updates for Swift 4.0 are made i can release specific betas on CocoaPods, sure

[ryanschneider]

FYI it sounds like the Cocoapods situation for Swift 4 hasn't been fully resolved: CocoaPods/CocoaPods#6791 This link has some potential solutions. The good news is that your Podfile can include all Swift 3 projects, and your main project can be Swift 4, as that's what I've been doing. During the migration, just upgrade your main xcodeproj to Swift 4, leave all your Pods unchecked in the first screen of the migration wizard. Currently, it sounds like if you want to have individual pods built with Swift 4, you need to use the `installer.pods_project.targets.each do |target|` loop suggested in the comments, as pod specs don't yet have a field for defining the Swift version of a project (understandably as Apple has changed the combat story w/ every Xcode release). So, until things shake out a little more, my suggestion would be for the official Gloss release to remain Swift 3.2, and for most people to use Swift 3.2-compatible pods in their Podfile. If Gloss 1.3 was released as Swift-4 only code before Cocoapods adds Swift version support to the pod spec DSL it'll probably just cause more confusion and Github issues to be opened than it's worth at the moment.

…

On Fri, Sep 15, 2017 at 8:26 AM, Harlan Kellaway ***@***.***> wrote: @ergunkocak <https://github.com/ergunkocak> swift_4.0 is currently the same as master so you can point to 1.2.4 in your private spec. once updates for Swift 4.0 are made i can release specific betas on CocoaPods, sure — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#296 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADREItS8FBmlNPiUdL98ESZQlp7TwqMks5sipcegaJpZM4NxFog> .

[hkellaway]

thats good to know, tnx @ryanschneider

[hkellaway]

fyi - version 2.0.0-beta.1 has been released with minimum changes for Swift 4 compability

[GabrielAraujo]

@hkellaway do you need some help fully migrating to swift 4?

[hkellaway]

@GabrielAraujo i appreciate you asking - i could use assistance.

version 2.0.0-beta.1 should work with Swift 4. however, it would be nice to have uniquely named protocols to disambiguate from Foundation. i was thinking JSONDecodable and JSONEncodable.

are there other Swift 4 migration tasks you see?

[GabrielAraujo]

@hkellaway I would go with something gloss unique like GlossDecodable and GlossEncodable to avoid this happening again in the future. Hahah

I don't think so.. This is the only thing the compiler is complaining.

I think it would be great to release the swift 4.0 as the official so the projects that depend on gloss like moya-gloss can also be migrated! =)

[hkellaway]

@GabrielAraujo i think i still prefer JSONDecodable and JSONEncodable, more descriptive

if you'd like to help move to that, that'd be great

[GabrielAraujo]

@hkellaway I began to perform the changes to JSONDecodable and JSONEncodable but I also noticed that Encoder, Decoder, JSONEncoder and JSONDecoder are already being used by swift. Do you think we should also change the names for Encoder and Decoder or is it just too much? hahah
https://github.com/GabrielAraujo/Gloss

[hkellaway]

thanks @GabrielAraujo! im okay leaving those as-is

[GabrielAraujo]

@hkellaway
#311

[hkellaway]

naming will be updated to JSONDecodable and JSONEncodable as of version 2.0.0-beta.2

thanks @GabrielAraujo!

[GabrielAraujo]

@hkellaway glad to help!!

Man, is there any remaining changes in the roadmap? Why is it beta?

[hkellaway]

just giving folks time to report any issues with the Swift 4 version before the official release of 2.0

there is one outstanding PR submitted before Swift 4 transition I want to revisit