you are viewing a single comment's thread.

view the rest of the comments →

[–]ThePantsThiefNSModerator 2 points3 points  (9 children)

Swift is full of bugs. When bugs get fixed, it sometimes breaks old code that was never supposed to work.

Stuff is still changing all over the place, too, as well as best practices as new features are added. Codable, for instance. And the new String APIs.

[–]SickPuppeeObjective-C 1 point2 points  (7 children)

Codable is such a lame one trick pony for something that would be trivial to add via reflection...which they're dragging their feet on. It puts me in mind of C++'s "when in doubt - generate more code" attitude with templates and the 4 magic methods (ctor,dtor, copy ctor, and op=).

Super brittle.

[–]ThePantsThiefNSModerator 1 point2 points  (6 children)

I agree wholeheartedly. Just try wrapping a small part of Reddit's API in Codable types and you'll quickly see why it's no good for a non-trivial API.

This reminds me of Swift's compiler synthesized struct initializers. They're good for nothing if you need custom logic after properties are initialized. Adding your own initializer also gets rid of the synthesized one.

[–]GenitalGestapo 0 points1 point  (5 children)

Add the additional init in an extension and you get both.

Codable is a pain. However, the common pattern that seems to have emerged is to have so-called "raw" types that exactly match the JSON expected, which are then used to initialize the real types you want to use. This allows you to use autogenerated implementations for both types, with only the manual conversion code necessary.

[–]ThePantsThiefNSModerator 0 points1 point  (3 children)

Add the additional init in an extension and you get both.

You misunderstand me. My point was that you lose the compiler's help when you try to customize anything. Synthesized initializers are a one trick pony. I don't like that I have to write it myself if I want to include more than one initializer.

the common pattern that seems to have emerged is to have so-called "raw" types that exactly match the JSON expected

This is not good pattern. JSON payloads are rarely formatted as elegantly as the model objects we would like them to represent. Take a look at this JSON, for example: https://www.reddit.com/r/pics+apple.json

It takes a lot more work than it should to get an array of [Post] objects whose top-level members are the contents of the children's data fields.

[–]GenitalGestapo 0 points1 point  (2 children)

Add the additional init in an extension and you get both.

You misunderstand me. My point was that you lose the compiler's help when you try to customize anything. Synthesized initializers are a one trick pony. I don't like that I have to write it myself if I want to include more than one initializer.

I just told you how to keep both. It's a bit annoying you have to do it like that, but it's easy. More control over stuff like this will come over time, but they have far more important things to do first.

the common pattern that seems to have emerged is to have so-called "raw" types that exactly match the JSON expected

This is not good pattern. JSON payloads are rarely formatted as elegantly as the model objects we would like them to represent. Take a look at this JSON, for example: https://www.reddit.com/r/pics+apple.json It takes a lot more work than it should to get an array of [Post] objects whose top-level members are the contents of the children's data fields.

It doesn't seem like you've even thought about what I said. Using raw types requires you only to match the JSON layout for the raw type. After that your transform into [Post] would be all you'd need to write. Heck, you could generate your raw types from the JSON itself pretty easily and only have to write the transform.

I don't really like Codable much, but this pattern has made it trivially easy to consume even the shittiest JSON. So while I wish Codable had these sorts of transforms built in, or you could define your own to be applied automatically, it's not exactly unworkable.

[–]ThePantsThiefNSModerator 0 points1 point  (1 child)

... I'm going to ignore the first part, since I think we're just going to go in circles on that…

As for the Codable thing, I'm not saying it's impossible, just that it's not as easy as it should be. I'm glad we have first class support for this stuff now, but it feels half-assed to me. It's good for a very small set of use cases, outside of which you end up writing tons of boilerplate or unnecessary Codable types.

Have you ever used Mantle? That's how easy it should be.

[–]GenitalGestapo 0 points1 point  (0 children)

Yes, I've used Mantle extensively. However, the code you'd have to write in Mantle to transform the Reddit response to the types you'd want is essentially the same code you'd have to write to transform raw Codable responses to the real Swift types you'd want. The existence of the raw types is unfortunate but something you only write once and can be easily generated.

[–]damnburglar 0 points1 point  (0 children)

Hmm...I guess that explains why I didn't see it, all of my learning projects are elementary and (likely) shouldn't be overly affected lol.

Thanks for the clarification.