An old problem seems to have resurfaced with a new head. We are breaking up large (more than 11 elements) objects into intermediate parts in order to appease the compiler. However, with the migration to Argo 2.0 and Swift 2, the compiler has a new complaint. Take this case (names made neutral):

public static func decode(j: JSON) -> Decoded<DataObject> {
    let firstPart =  DataObject.create
        <^> j <| "data1"
        <*> j <| "data2"
        <*> j <| "data3"
        <*> j <|? "data4"
        <*> j <|? "data5"

    let secondPart = firstPart
        <*> j <|? "data6"
        <*> j <|? "data7"
        <*> j <|? "data8"
        <*> j <|? "data9"
        <*> j <|? "data10"

    let thirdPart = secondPart
        <*> j <|? "data11"
        <*> j <|? "data12"
        <*> j <|? "data13"
        <*> j <|? "data14"
        <*> j <|? "data15"

    let fourthPart = thirdPart
        <*> j <|? "data16"
        <*> j <|? "data17"
        <*> j <|? "data18"
        <*> j <|? "data19"
        <*> j <|? "data20"

    return fourthPart
        <*> j <|? "data21"
        <*> j <|? "data22"
        <*> j <|? "data23"
        <*> j <|| "data24"
        <*> j <|| "data25"
        <*> j <|| "data26"
        <*> j <|? "data27"
}

The compiler complains in two spots (the second line of the secondPart assignment and the second line of the thirdPart assignment) about an "Ambiguous reference to member <|?". Does anyone know a way to get around this that doesn't involve breaking up the DataObject itself into multiple smaller objects that then get merged?

I’m getting an error Expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions when using Argo to parse GitHub’s pull request JSON into my struct. I have the following decoder:

static var decoder: JSONValue -> PullRequest? {
        return PullRequest.create
            <^> <|"number"
            <*> <|"state"
            <*> <|"title"
            <*> <||"labels"
            <*> <|*"created_at"
            <*> <|*"updated_at"
            <*> <|*"merged_at"
            <*> <|*"closed_at"
            <*> <|["user", "login"]
            <*> <|*"assignee"
            <*> <|["repository", "owner", "login"]
            <*> <|"comments"
            <*> <|"html_url"
            <*> <|*"statuses_url"
}

That is 14 properties for the pull request entity from GitHub’s API (which returns a ton more). I’m currently using the code in #2 as master would lead to the compiler and indexer more or less hanging (they did not but they never finished in reasonable time ^^).

This seems to be caused by a bug in swiftc where only 11 statements per expression works.

Do you have a suggestion for workaround of this? As it would be great to be able to have more than 11 properties :smile:

I found that on a 4S device, my data model was taking almost 12 seconds, to be parsed. So I did a small experiment with the following:

import Foundation
import Argo
import Curry
import Runes

struct Person {

    let firstName: String
    let secondName: String?
    let age: Int
    let hoobies: [String]
    let description: String
}

extension Person: Decodable {

    static func decode(j: JSON) -> Decoded<Person> {
        return curry(Person.init)
            <^> j <| "firstName"
            <*> j <|? "secondName"
            <*> j <| "age"
            <*> j <|| "hobbies"
            <*> j <| "description"
    }
}

This is not my original model, but a far simpler one. So I used a testing file with 100k lines of JSON with a total of 9130 objects. The original one has more than 330k lines and far deeper hierarchy and complexity (number of members).

I wasn't sure which would the best approach so I used the ones I saw in the wild (the measurements are in release mode on a MacbookPro 2015):

Then I did the parsing "by hand":

Obviously, the second version has a lot more boilerplate, it's not as easy to maintain or extend, but in this case all those niceties are not worth with such timings. A demo project can be found here.

Is there any planned support for reversing the decode process and encoding back to JSON? I'm thinking this could be a good way to also automatically support serialization to disk.

I integrated Argo with my project ( Swift 1.2, Xcode 6.4 ). I wanna move to the Xcode 7 beta 6, with Swift 2.0. I want to integrate argo with Swift 2.0. When i imported project to Xcode 7 beta 6, it suggested lot of code changes from Swift 1.2 to Swift 2.0. Which was really bad, i really could not understand what Xcode did to my project.

Could you please tell me that, which is the best way, updating via cocoapods ? Do i have to wait till the release of Xcode 7, Cause i decided that i will be taking Argo with my app to the production. So i don't want to waste time by integrating again and solving the bugs.

May i wait till the release of Xcode 7 ? or this Argo gonna behave the same without any problem in Xcode 7.

Suggest me your thoughts.

I have Argo embedded within my existing project (and have had for ages). I'm finally getting around to updating to Swift 3.

I updated my project's Cartfileto point to Argo master (instead of 3.1.0):

github "thoughtbot/Argo" "master"

and run carthage update --use-submodules. This successfully fetches Argo and Runes. As you can see from the log below, Runes compiles OK and I can see the artifacts in the Carthage/Build/XXX folders. However, when it tried to build Argo, I get an error saying that it can't find the Runes module.

There is a mention of a similar problem in #407 (which I don't think is related to the PR... just a similar problem).

I've tried a bunch of carthage combos (bootstrap, build, update, et al), but just can't get a working build.

I'm still digging through the logs, but any thoughts would be great.

Error Messages

*** xcodebuild output can be found in /var/folders/p6/xcv59nqd4wv0y6hwpm3q16m40000gn/T/carthage-xcodebuild.7gtojh.log
*** Building scheme "Runes-tvOS" in Runes.xcodeproj
*** Building scheme "Runes-Mac" in Runes.xcodeproj
*** Building scheme "Runes-iOS" in Runes.xcodeproj
*** Building scheme "Runes-watchOS" in Runes.xcodeproj
*** Building scheme "Argo-watchOS" in Argo.xcworkspace
** BUILD FAILED **


The following build commands failed:
    CompileSwift normal armv7k
    CompileSwiftSources normal armv7k com.apple.xcode.tools.swift.compiler
    Ld /Users/edwardsc/Library/Developer/Xcode/DerivedData/Argo-asybjaazisryjmeuwabufbberqcz/Build/Products/Release-watchos/Argo.framework/Argo normal armv7k
    GenerateDSYMFile /Users/edwardsc/Library/Developer/Xcode/DerivedData/Argo-asybjaazisryjmeuwabufbberqcz/Build/Products/Release-watchos/Argo.framework.dSYM /Users/edwardsc/Library/Developer/Xcode/DerivedData/Argo-asybjaazisryjmeuwabufbberqcz/Build/Products/Release-watchos/Argo.framework/Argo
(4 failures)
/Users/edwardsc/dev/Ogra/Carthage/Checkouts/Argo/Argo/Types/Decoded/Applicative.swift:1:8: error: no such module 'Runes'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: cannot parse the debug map for "/Users/edwardsc/Library/Developer/Xcode/DerivedData/Argo-asybjaazisryjmeuwabufbberqcz/Build/Products/Release-watchos/Argo.framework/Argo": No such file or directory
A shell task failed with exit code 65:
** BUILD FAILED **


The following build commands failed:
    CompileSwift normal armv7k
    CompileSwiftSources normal armv7k com.apple.xcode.tools.swift.compiler
    Ld /Users/edwardsc/Library/Developer/Xcode/DerivedData/Argo-asybjaazisryjmeuwabufbberqcz/Build/Products/Release-watchos/Argo.framework/Argo normal armv7k
    GenerateDSYMFile /Users/edwardsc/Library/Developer/Xcode/DerivedData/Argo-asybjaazisryjmeuwabufbberqcz/Build/Products/Release-watchos/Argo.framework.dSYM /Users/edwardsc/Library/Developer/Xcode/DerivedData/Argo-asybjaazisryjmeuwabufbberqcz/Build/Products/Release-watchos/Argo.framework/Argo
(4 failures)

Argo Version

master (4b57653f7760bd3eedfd1c1fbc821bde191e603d)

Dependency Manager

Carthage

I'm using the same approach as in the iTunes Example Playground to convert a String to a NSDate, like so:

extension App: Decodable  {
  ...

  static func decode(j: JSON) -> Decoded<App> {
    return create
      <^> j <| "trackName"
      <*> j <| "formattedPrice"
      <*> j <|? "averageUserRating"
      <*> (j <| "releaseDate" >>- toNSDate)
  }
}

However, I've also needed to break up the expression, similar to:

extension App: Decodable  {
  ...

  static func decode(j: JSON) -> Decoded<App> {
    let app = create
      <^> j <| "trackName"
      <*> j <| "formattedPrice"
    return app
      <*> j <|? "averageUserRating"
      <*> (j <| "releaseDate" >>- toNSDate)
  }
}

This results in the following error message:

Binary operator '<*>' cannot be applied to operands of type 'Decoded<NSDate -> App>' and 'Decoded<App>'

Argo’s performance is quadratic over the size of the collection being decoded, due to the use of reduce (AirspeedVelocity article). This PR removes most usages of reduce in exchange for a for loop of the same functionality. This improves the performance of decoding an array of over 9000 simple models on an iPhone 4S by ~2600% (76.4s to 2.9s). See #295 for my analysis and evolution of this code.

// // CommentItem.swift // xxxxxxxxxxxxxxx // // Created by xxxxxxx on 10/20/15. // Copyright © 2015 xxxxxx. All rights reserved. //

import Argo import Curry

struct CommentItem { let fromUserId: String? let toUserId: String? let content: String? let timestamp: Int64? }

extension CommentItem: Decodable { static func decode(j: JSON) -> Decoded { return curry(UACCommentItem.init) <^> j <| "fromUserId" <> j <|? "toUserId" <> j <| "content" <*> j <| "timestamp" } }

Above is code, swift 2.0, Version 7.0.1 (7A1001), i have this problem. the line of problem is "<*> j <| "timestamp""

I'm using Argo in production app, and I can see that the Swift compile time takes a lot of time in my project. Wondering if this is because of Argo & Argo based models which use a lot of generic code ? Please let me know if you have done any bench marking around this.

Argo Version

Argo 3.1

Dependency Manager

Carthage

I have JSON that is analogous to this:

{
  "animals": [
    { "type": "cat", "name": "kitty", "remainingLives": 4 },
    { "type": "dog", "name": "spot", "trained": false }
  ]
}

I would love to have an Animal type with a name property and then a subclass for Cat with a remainingLives property and Dog with a trained property.

It doesn't appear to be possible with Argo. Am I missing anything? If not, is this something that you think might fit into Argo? I would be happy to work on it with a little guidance. (I'm very new to Swift)

Previously, we've used a special operator (<|?) for denoting that we were decoding to an optional property. This operator had special behavior that meant it would only fail if the decoding operation itself failed, but would still succeed if the key was missing.

I think that ultimately, this was a confusing distinction. Although it was nice and concise, it made it difficult to reason about some transformations (like flatMapping into a secondary transformation), and it also meant we needed to double the surface area of the API. The special behavior around when we failed the decoding was also potentially confusing and could lead to unexpected results for people that weren't completely familiar with the distinction between how we handled various decoding failures internally.

Additionally, we've had another solution to this problem for nearly the entire time this library has existed: Decoded.optional. This is a much simpler transformation, and it simply converts the Decoded to an Optional and then wraps it in .success.

It seems reasonable, then (especially with the additional API changes currently in flight) to reduce the surface area and the complexity of our API at the same time by removing the <|? operators in favor of explicitly wrapping our extraction operations in a call to .optional.

Note that this also means we can use conditional conformance to make conform Optional conform to Decoded directly.

I've finally gotten some time to work on this, and I'd like to push forward with solving the naming conflict between Swift.Decodable and Argo.Decodable. I've also opened up #473 to rename JSON to Value.

I'd like to get thoughts from people on the naming of the Decodable protocol. I'm not sure that I have super strong opinions on what to name it, and I'd be willing to bet other people do.

Prior Art

One quick data point that we can probably immediately disregard:

Aeson calls their version of Decodable FromJSON. Their decode function is then called fromJSON. I think that given our move away from using JSON in our naming, it doesn't make sense to follow their lead here.

Proposal: WeakTypeConvertable

One idea I keep coming back to is the idea that (from a marketing standpoint) we can push this idea of moving from weak -> strong data types via the protocol. This isn't nearly as catchy a name as Decodable (or even FromJSON), but it seems to be more descriptive. An interface for this might look like:

public protocol WeakTypeConvertable {
  associatedtype TargetType = Self
  static func decode(_ value: Value) -> Decoded<TargetType>
}

The one thing (other than the clumsiness of the overall name) I don't like is that it feels like this pulls me down a rabbit hole for the function/result names. It seems to me that we might want to move all the way to something more like:

public protocol WeakTypeConvertable {
  associatedtype TargetType = Self
  static func fromValue(_ value: Value) -> Converted<TargetType>
}

It's not too difficult to see how this can start to spiral into a much larger rename where we touch every part of the lib. I'd imagine this level of change would be incredibly painful for end users.

I'd love to hear thoughts on this from people that have a vested interest in the end result.

related: #466, #471

We're going to be shifting the marketing focus for Argo away from being a JSON parser and towards being a general purpose parser for transforming loosely typed data models into strongly typed ones. As a part of this change, we can generalize our types a bit, and use the name Value for our input values, instead of JSON. This change is purely cosmetic, but will result in a more general API, letting us break a bit from our ties to JSON.

Note that we're providing a typealias from JSON to Value here as well. This should make this a non-breaking change (although users will get a deprecation warning). I'd love it if other people could test this with their codebase.

I'm trying to convert some code to use Argo, and I'm getting stuck where the existing code uses subclasses. I can't get type inference to pass.

If anyone knows how to get this to work, I'd love some help.

Error Messages

error: cannot convert value of type 'Decoded<_>' to specified type 'Decoded<Child>'
    let child: Decoded<Child> = json <| "child"
                                ~~~~~^~~~~~~~~~
error: cannot convert value of type 'Decoded<[_]?>' (aka 'Decoded<Optional<Array<_>>>') to specified type 'Decoded<[Child]?>' (aka 'Decoded<Optional<Array<Child>>>')
    let children: Decoded<[Child]?> = json <||? "children"
                                      ~~~~~^~~~~~~~~~~~~~~

Models

class Parent: Decodable {
  let title: String

  init(title: String) {
    self.title = title
  }

  typealias DecodedType = Parent
  static func decode(_ json: JSON) -> Decoded<Parent> {
    return curry(Parent.init)
      <^> json <| "title"
  }
}

class Child: Parent {
  let subtitle: String

  init(title: String, subtitle: String) {
    self.subtitle = subtitle
    super.init(title: title)
  }

  typealias DecodedType = Child
  static func decode(_ json: JSON) -> Decoded<Child> {
    return curry(Child.init)
      <^> json <| "title"
      <*> json <| "subtitle"
  }
}

final class Consumer: Decodable {
  let child: Child
  let children: [Child]?

  init(child: Child, children: [Child]?) {
    self.child = child
    self.children = children
  }

  static func decode(_ json: JSON) -> Decoded<Consumer> {
    // Changing these from Child to Parent makes it work
    let child: Decoded<Child> = json <| "child"
    let children: Decoded<[Child]?> = json <||? "children"
    return curry(self.init)
      <^> child
      <*> children
  }
}

Argo Version

Argo 4.1.2 Xcode 8.3.2

Dependency Manager

Carthage

Sample JSON

{
  "aggregations": {
    "my_aggregation": {
      "value": 9
    }
  }
}

Models

let int: Decoded<Int> = json <| ["aggregations", "device_count", "value"]
// ^ missingKey("value")

Argo Version

4.1.2

Dependency Manager

Swift Package Manager.

This only occurs under Linux. Locally, there's no problem on MacOS. Under the debugger it seemed to be showing that value was present but its value was null, as if {"value": null}.

Resolved this way (ugh).

let dict = json as? [String:Any]

let int = dict.flatMap({ d -> Any? in
    return d["aggregations"]
}).flatMap({  d -> [String:Any]? in
    return d as? [String:Any]
}).flatMap({ d -> Any? in
    return d["my_aggregation"]
}).flatMap({ d -> [String:Any]? in
   return d as? [String:Any]
}).flatMap({ d -> Any? in
    return d["value"]
}).flatMap({ d -> Int? in
   return d as? Int
})

I assume this is related to NSNumber being a shitshow on Linux, and thus isn't really Argo's problem. This issue is more for the benefit of everyone else.

(Related observation: if NSNumber's crufty addition of so many features is due to years of the "benefits" of ABI stability, I'm terrified for the consequences of Swift 5).