This is a really great proposal. As an iOS developer I work with JSON
almost every day since most mobile apps communicate with a backend through
JSON messages. It's good to see that better JSON support is coming to
Foundation so we don't have to rely on third party libraries.
That being said, there is one thing I don't like which is that the JSON
encoding function returns Data and the decoding function takes Data.
It would be really great if the Foundation team could introduce a dedicated
type of JSON.
There are several advantages of working with a dedicated type.
- The underlying data is always valid JSON
- You can extend this type in the future with helper methods for
manipulating JSON
- It makes it explicit what you are dealing with
A good analogy is the URL type. You could represent an URL with a String or
Data type, but by introducing a dedicated type you have the full advantages
mentioned above. Data on the other hand is like a generic container which
you cannot easily extend with URL or JSON specific methods.
Having a dedicated JSON type is also one of the reasons third party
libraries like SwiftyJSON are so popular. It makes it super easy to
manipulate JSON structures. And sometimes developers like would like to
manipulate JSON directly.
If the proposal would pass in the current form, I would still use
SwiftyJSON for manipulating JSON which I would rather avoid and have this
all sorted on the Foundation level.
Just my two cents from the perspective of an iOS developer. JSON handling
is really important to us so I hope you make it great!
···
------------------------------------------------
Hello Swift community,
The review of SE-0167 "Swift Encoders" begins now and runs through
April 12, 2017. The proposal is available here:
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the
direction of Swift. When writing your review, here are some questions
you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
More information about the Swift evolution process is available at
This is a really great proposal. As an iOS developer I work with JSON almost every day since most mobile apps communicate with a backend through JSON messages. It's good to see that better JSON support is coming to Foundation so we don't have to rely on third party libraries.
That being said, there is one thing I don't like which is that the JSON encoding function returns Data and the decoding function takes Data.
It would be really great if the Foundation team could introduce a dedicated type of JSON.
There are several advantages of working with a dedicated type.
- The underlying data is always valid JSON
- You can extend this type in the future with helper methods for manipulating JSON
- It makes it explicit what you are dealing with
A good analogy is the URL type. You could represent an URL with a String or Data type, but by introducing a dedicated type you have the full advantages mentioned above. Data on the other hand is like a generic container which you cannot easily extend with URL or JSON specific methods.
Having a dedicated JSON type is also one of the reasons third party libraries like SwiftyJSON are so popular. It makes it super easy to manipulate JSON structures. And sometimes developers like would like to manipulate JSON directly.
I don’t think it would be a good thing to have this in Foundation. Foundation needs to push developers towards adopting best practices, and manipulating JSON directly instead of going through Codable’s strong-typing is not necessarily recommended. I’m not saying it doesn’t have its uses. But it’s usefulness is definitely narrow now once we have Codable. I think this is something that should stay in a third-party library.
···
On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution <swift-evolution@swift.org> wrote:
If the proposal would pass in the current form, I would still use SwiftyJSON for manipulating JSON which I would rather avoid and have this all sorted on the Foundation level.
Just my two cents from the perspective of an iOS developer. JSON handling is really important to us so I hope you make it great!
------------------------------------------------
Hello Swift community,
The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 2017. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
I haven't thought heavily about this, but the thoughts that I have say that JSON just isn't a good type in Swift. It's not an efficient in-memory representation and it's not a convenient structural representation (because of the use of either 'Any' or 'JSON' in the recursive position). I'll admit that sometimes you're handed some JSON and you want to extract a little bit of information out of it without building a typed representation of the whole thing, but that still seems like something that doesn't need to be the common path.
Jordan
···
On Apr 10, 2017, at 02:52, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is a really great proposal. As an iOS developer I work with JSON almost every day since most mobile apps communicate with a backend through JSON messages. It's good to see that better JSON support is coming to Foundation so we don't have to rely on third party libraries.
That being said, there is one thing I don't like which is that the JSON encoding function returns Data and the decoding function takes Data.
It would be really great if the Foundation team could introduce a dedicated type of JSON.
There are several advantages of working with a dedicated type.
- The underlying data is always valid JSON
- You can extend this type in the future with helper methods for manipulating JSON
- It makes it explicit what you are dealing with
A good analogy is the URL type. You could represent an URL with a String or Data type, but by introducing a dedicated type you have the full advantages mentioned above. Data on the other hand is like a generic container which you cannot easily extend with URL or JSON specific methods.
Having a dedicated JSON type is also one of the reasons third party libraries like SwiftyJSON are so popular. It makes it super easy to manipulate JSON structures. And sometimes developers like would like to manipulate JSON directly.
I don’t think it would be a good thing to have this in Foundation. Foundation needs to push developers towards adopting best practices, and manipulating JSON directly instead of going through Codable’s strong-typing is not necessarily recommended. I’m not saying it doesn’t have its uses. But it’s usefulness is definitely narrow now once we have Codable. I think this is something that should stay in a third-party library.
This is a really great proposal. As an iOS developer I work with JSON almost every day since most mobile apps communicate with a backend through JSON messages. It's good to see that better JSON support is coming to Foundation so we don't have to rely on third party libraries.
That being said, there is one thing I don't like which is that the JSON encoding function returns Data and the decoding function takes Data.
It would be really great if the Foundation team could introduce a dedicated type of JSON.
There are several advantages of working with a dedicated type.
- The underlying data is always valid JSON
- You can extend this type in the future with helper methods for manipulating JSON
- It makes it explicit what you are dealing with
A good analogy is the URL type. You could represent an URL with a String or Data type, but by introducing a dedicated type you have the full advantages mentioned above. Data on the other hand is like a generic container which you cannot easily extend with URL or JSON specific methods.
Having a dedicated JSON type is also one of the reasons third party libraries like SwiftyJSON are so popular. It makes it super easy to manipulate JSON structures. And sometimes developers like would like to manipulate JSON directly.
I don’t think it would be a good thing to have this in Foundation. Foundation needs to push developers towards adopting best practices, and manipulating JSON directly instead of going through Codable’s strong-typing is not necessarily recommended. I’m not saying it doesn’t have its uses. But it’s usefulness is definitely narrow now once we have Codable. I think this is something that should stay in a third-party library.
I haven't thought heavily about this, but the thoughts that I have say that JSON just isn't a good type in Swift. It's not an efficient in-memory representation and it's not a convenient structural representation (because of the use of either 'Any' or 'JSON' in the recursive position). I'll admit that sometimes you're handed some JSON and you want to extract a little bit of information out of it without building a typed representation of the whole thing, but that still seems like something that doesn't need to be the common path.
I agree. It seems orthogonal to this proposal to me. It would be easy enough for a library to add a Codable JSON type on top of this proposal. Foundation could even do that in the future if there was strong enough motivation for it.
···
On Apr 10, 2017, at 3:47 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
On Apr 10, 2017, at 02:52, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
For me it boils down to a question if Data is the best type to represent
JSON. Data is really generic, you could serialize an UIImage into data and
pass it to the decoding function.
Yes, JSON is not a very strong type but that is the nature of JSON, it is a
dynamic data structure like a dictionary. But giving it a type gives us
future flexibility to extend it if needed.
Also, raw JSON manipulation is common practice since the server does not
always give you the perfect JSON to deserialize into a model object.
Say you have a model object with some nested objects in it. To initialize
them from JSON you will need to full JSON for all the objects. But the
common practice is that the server will return only the full top level
object and IDs for the nest d objects so you fetch them separately.
···
W dniu pon., 10.04.2017 o 22:47 Jordan Rose <jordan_rose@apple.com> napisał(a):
On Apr 10, 2017, at 02:52, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:
On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution < > swift-evolution@swift.org> wrote:
This is a really great proposal. As an iOS developer I work with JSON
almost every day since most mobile apps communicate with a backend through
JSON messages. It's good to see that better JSON support is coming to
Foundation so we don't have to rely on third party libraries.
That being said, there is one thing I don't like which is that the JSON
encoding function returns Data and the decoding function takes Data.
It would be really great if the Foundation team could introduce a
dedicated type of JSON.
There are several advantages of working with a dedicated type.
- The underlying data is always valid JSON
- You can extend this type in the future with helper methods for
manipulating JSON
- It makes it explicit what you are dealing with
A good analogy is the URL type. You could represent an URL with a String
or Data type, but by introducing a dedicated type you have the full
advantages mentioned above. Data on the other hand is like a generic
container which you cannot easily extend with URL or JSON specific methods.
Having a dedicated JSON type is also one of the reasons third party
libraries like SwiftyJSON are so popular. It makes it super easy to
manipulate JSON structures. And sometimes developers like would like to
manipulate JSON directly.
I don’t think it would be a good thing to have this in Foundation.
Foundation needs to push developers towards adopting best practices, and
manipulating JSON directly instead of going through Codable’s strong-typing
is not necessarily recommended. I’m not saying it doesn’t have its uses.
But it’s usefulness is definitely narrow now once we have Codable. I think
this is something that should stay in a third-party library.
I haven't thought *heavily* about this, but the thoughts that I have say
that JSON just isn't a good type in Swift. It's not an efficient in-memory
representation and it's not a convenient structural representation (because
of the use of either 'Any' or 'JSON' in the recursive position). I'll admit
that sometimes you're handed some JSON and you want to extract a little bit
of information out of it without building a typed representation of the
whole thing, but that still seems like something that doesn't need to be
the common path.
For me it boils down to a question if Data is the best type to represent JSON. Data is really generic, you could serialize an UIImage into data and pass it to the decoding function.
Data is what you read from and write to disk and network and therefore the appropriate choice for these APIs.
···
Sent from my iPad
On Apr 12, 2017, at 2:53 AM, piotr gorzelany via swift-evolution <swift-evolution@swift.org> wrote:
Yes, JSON is not a very strong type but that is the nature of JSON, it is a dynamic data structure like a dictionary. But giving it a type gives us future flexibility to extend it if needed.
Also, raw JSON manipulation is common practice since the server does not always give you the perfect JSON to deserialize into a model object.
Say you have a model object with some nested objects in it. To initialize them from JSON you will need to full JSON for all the objects. But the common practice is that the server will return only the full top level object and IDs for the nest d objects so you fetch them separately.
W dniu pon., 10.04.2017 o 22:47 Jordan Rose <jordan_rose@apple.com> napisał(a):
On Apr 10, 2017, at 02:52, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution <swift-evolution@swift.org> wrote:
This is a really great proposal. As an iOS developer I work with JSON almost every day since most mobile apps communicate with a backend through JSON messages. It's good to see that better JSON support is coming to Foundation so we don't have to rely on third party libraries.
That being said, there is one thing I don't like which is that the JSON encoding function returns Data and the decoding function takes Data.
It would be really great if the Foundation team could introduce a dedicated type of JSON.
There are several advantages of working with a dedicated type.
- The underlying data is always valid JSON
- You can extend this type in the future with helper methods for manipulating JSON
- It makes it explicit what you are dealing with
A good analogy is the URL type. You could represent an URL with a String or Data type, but by introducing a dedicated type you have the full advantages mentioned above. Data on the other hand is like a generic container which you cannot easily extend with URL or JSON specific methods.
Having a dedicated JSON type is also one of the reasons third party libraries like SwiftyJSON are so popular. It makes it super easy to manipulate JSON structures. And sometimes developers like would like to manipulate JSON directly.
I don’t think it would be a good thing to have this in Foundation. Foundation needs to push developers towards adopting best practices, and manipulating JSON directly instead of going through Codable’s strong-typing is not necessarily recommended. I’m not saying it doesn’t have its uses. But it’s usefulness is definitely narrow now once we have Codable. I think this is something that should stay in a third-party library.
I haven't thought heavily about this, but the thoughts that I have say that JSON just isn't a good type in Swift. It's not an efficient in-memory representation and it's not a convenient structural representation (because of the use of either 'Any' or 'JSON' in the recursive position). I'll admit that sometimes you're handed some JSON and you want to extract a little bit of information out of it without building a typed representation of the whole thing, but that still seems like something that doesn't need to be the common path.