vdka / json Goto Github PK

Use the abstract Data type also known as [UTF8.CodeUnit] everywhere and wrap these methods with convenience String methods. It is best for performance if everything can be done with raw data rather than Swift's monolithic String type.

Currently the way we test for JSON fragments is to see if the first non whitespace character is a '{' | '['. Being so naive fails once you allow comments. We should instead go to the simpler solution of Parsing the whole lot and then checking if the value we got back was a fragment (at least when we allow comments).

hi, i hope to add Codable instance to JSON method, could you help me

The parser maintains a sort of stack using a bufferPointer and a pointer it is the consumer of the stack API to ensure that memory is not deallocated while using the stack.

As seen when looking through the Lexer for Swift the case /*/ may need a little special handling.
It's actually an syntax error but currently doesn't throw one.
https://github.com/apple/swift/blob/master/lib/Parse/Lexer.cpp#L356

Null characters can be replaced based off what we already know (terminating " characters have been replaced with null for String.fromCString(unsafeBitCast(startAddress, UnsafePointer<CChar>.self))!)

After adding Carthage support it doesn't build anymore in Xcode

Source files of JSON target don't know JSON type because JSONCore is not imported

Functioning linux tests would be great and some consistent testing pattern.

• Parser (98% coverage)
• Serializer (81% coverage)
• Accessors (41% coverage)

Thanks for a great JSON parsing library! Compared to others, I've found this to perform faster for my use case.

Swift 4 comes with built-in JSON coding support with Codable, but early benchmarks show that it's quite slow, and it doesn't seem to be a good fit for working with third party APIs (requires custom models for every different JSON response).

Will there be a Swift 4 update for JSON.swift in the near future?

Currently there is a non functional implementation for error position reporting below.

It should be possible to grab the offset of the buffer's base pointer from the current pointer to find the location of the parser at time of error. Next by iterating over the characters in the buffer and counting characters and newline characters the line & column values should be determinable without tracking their values throughout parsing. This will result in faster parsing when valid JSON is provided and only slightly worse performance on errors (worse the further into the JSON the error occurs)

  public static func parse(string: String, options: [Option] = []) throws -> JSON {
    var parser = self.init(string: string, options: options)
    var json: JSON = []
    do {
      json = try parser.parseValue()
    } catch let code as ErrorCode { // TODO: Make this work, or DEPRECATE it.
      let charsIn = parser.scalars.count - parser.buffer.count
      print("Parsed up to: \n\(parser.scalars[0..<charsIn].map({ String($0) }).joinWithSeparator(""))")
      var line: UInt = 0
      var char: UInt = 0
      for ch in parser.scalars.prefix(charsIn) {
        switch ch {
        case newline:
          line += 1
          char  = 0

        default:
          char += 1
        }
      }
      throw Error(char: char, line: line, code: code)
    }
    return json
  }

Need to add a CFBundleVersion For App Store submissions.

• JSON.Parser
• JSON.Serializer
• JSON.accessors
• extension Optional
• JSONEncodable
• JSONDecodable

When Swift 3.1 comes we can add

extension Optional where Wrapped == JSON {
    var isNull: Bool {
        guard let `self` = self else { return true }
        return self.isNull
    }
}

Now that Swift 3 is released the framework should have Carthage support added back in.

As far as I'm aware the Objective-C backed parser is much faster than the Swift one but it only works on Darwin.

What platform are you benchmarking on?

enum JSON {
//...
case .object([(String, JSON)])
//...
}

Accessors can then lazily build this into a dictionary as needed.

I have a json config that I'm reading from a file. After serializing and writing the resulting string to a file, this is what the file looks like:

{"downloadDirectory":"/var/lib/downloads","convert":false,"plexDirectory":"/var/lib/plexmediaserver/Library"}

If I read the file and try to initialize my JSON struct with the above string, it gives a 'badField' error for the "convert" field.

Something with the unquoted boolean string is causing issues with the let convert: Bool = json.get("convert") in my initializer

Hi,

Any plan to integrate your great lib via CocoaPod ?

import func Darwin.C.stdlib.strtod
import func Darwin.C.stdlib.strtoll

Currently number parsing is handled by the C functions above, there is also 2 iterations done over the number

• Store current parser position
• Iterate the parser until a number terminator is found taking note of indications of a floating point number
• Parse the number based off of indications of floating point numberness.

By creating our own parsing function we combine steps 2 & 3 and will not need step 1

Float's are painful. (Maybe always will be)

  // TODO (vdka): floating point accuracy
  func testNumber_Double_Exp_Negative() {

    // FIXME (vdka): Fix floating point number types
    expect("-24.3245e-2", toParseTo: -24.3245e-2)
  }

• SwiftyJSON
• JASON
• Argo
• Mapper
• ObjectMapper
• PMJSON
• JSONCore
• NSJSONSerialization
• coreFoundation/NSJSONSerialization

I can't even use the serializer on:

let msg: [String: JSONRepresentable] = ["name": "Robert"]

It may be significantly slower but it'd be good if the serializer could take Any and just recursively serialize it throwing an error if something isn't JSONRepresentable.

On a call to the .string property of a json object a string could be lazily initialized from an array of UTF8.CodeUnit

Initialization creates a scalars array using string.utf8.
This involves a copy.
NSJSONSerialization accepts data in the more raw NSData form.
Network data needn't be converted to the intermediate String form in order to be parsed.
The scalars property is also not required for operation. With some albeit difficult memory management the entire parser can be represented by options flags & 2 pointers (startAddress & endAddress)

Use of a concrete type providing an efficient implementation of an OrderedDictionary would improve access time performance.

"\"2017-01-29T22:33:33.360425644+10:00\"\n"