Idea: Exposing _JSONEncoder and _JSONDecoder functionality

In the implementation og JSONEncoder and JSONDecoder we have the internal
functionality that encodes Codable types to a structure that is compatible
with JSONSerialization.
The JSONEncoder then calls JSONSerialization on this structure - and
JSONDecoder vice versa.
In some situations it could be nice to just encode or decode to or from
this structure - and not have the final encoding to Data performed. For
instance if you have some library that hands you a structure in this format
and you would like to perform decoding.

Can anyone else see the relevance of exposing this functionality? It could
be exposed by wrapping _JSONEncoder in a public JSONStructureEncoder or
something similar.

Sincerely,
/morten

Hi Morten,

This is something we’ve considered adding and may do so in the future — however, this will require additional API review and will not make it in time for the Swift 4.0 release.
The usage of `JSONSerialization` as the serialization backend is a current implementation detail, and may change in future releases; it would, for instance, be more efficient to read/write JSON as we encode/decode, instead of trying to collect the entire object graph before performing the next step.

We could also introduce something like a general `StructureEncoder`/`StructureDecoder` which performs this conversion, as this might be useful outside of just JSON. (For instance, `PropertyListEncoder`/`PropertyListDecoder` currently do something similar.)

So yes, this is under consideration for future API. :slight_smile:

— Itai

···

On 25 Jul 2017, at 0:44, Morten Bek Ditlevsen via swift-evolution wrote:

In the implementation og JSONEncoder and JSONDecoder we have the internal
functionality that encodes Codable types to a structure that is compatible
with JSONSerialization.
The JSONEncoder then calls JSONSerialization on this structure - and
JSONDecoder vice versa.
In some situations it could be nice to just encode or decode to or from
this structure - and not have the final encoding to Data performed. For
instance if you have some library that hands you a structure in this format
and you would like to perform decoding.

Can anyone else see the relevance of exposing this functionality? It could
be exposed by wrapping _JSONEncoder in a public JSONStructureEncoder or
something similar.

Sincerely,
/morten
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hi Morten,

This is something we’ve considered adding and may do so in the future — however, this will require additional API review and will not make it in time for the Swift 4.0 release.
The usage of JSONSerialization as the serialization backend is a current implementation detail, and may change in future releases; it would, for instance, be more efficient to read/write JSON as we encode/decode, instead of trying to collect the entire object graph before performing the next step.

As a side note, if this could be pushed even further to allow encoding/decoding to/from a Stream, it would allow me to use Codable on a project where I’m parsing JSON files in the hundreds of Mbs. I have no choice but to use a streaming parser.

···

On 25 Jul 2017, at 18:45, Itai Ferber via swift-evolution <swift-evolution@swift.org> wrote:
We could also introduce something like a general StructureEncoder/StructureDecoder which performs this conversion, as this might be useful outside of just JSON. (For instance, PropertyListEncoder/PropertyListDecoder currently do something similar.)

So yes, this is under consideration for future API. :slight_smile:

— Itai

On 25 Jul 2017, at 0:44, Morten Bek Ditlevsen via swift-evolution wrote:

In the implementation og JSONEncoder and JSONDecoder we have the internal
functionality that encodes Codable types to a structure that is compatible
with JSONSerialization.
The JSONEncoder then calls JSONSerialization on this structure - and
JSONDecoder vice versa.
In some situations it could be nice to just encode or decode to or from
this structure - and not have the final encoding to Data performed. For
instance if you have some library that hands you a structure in this format
and you would like to perform decoding.

Can anyone else see the relevance of exposing this functionality? It could
be exposed by wrapping _JSONEncoder in a public JSONStructureEncoder or
something similar.

Sincerely,
/morten
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hi Morten,

This is something we’ve considered adding and may do so in the future — however, this will require additional API review and will not make it in time for the Swift 4.0 release.
The usage of JSONSerialization as the serialization backend is a current implementation detail, and may change in future releases; it would, for instance, be more efficient to read/write JSON as we encode/decode, instead of trying to collect the entire object graph before performing the next step.

As a side note, if this could be pushed even further to allow encoding/decoding to/from a Stream, it would allow me to use Codable on a project where I’m parsing JSON files in the hundreds of Mbs. I have no choice but to use a streaming parser.

+1 to eventually moving to a streaming implementation. This is something I have wanted at times as well.

···

On Jul 25, 2017, at 2:08 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

On 25 Jul 2017, at 18:45, Itai Ferber via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
We could also introduce something like a general StructureEncoder/StructureDecoder which performs this conversion, as this might be useful outside of just JSON. (For instance, PropertyListEncoder/PropertyListDecoder currently do something similar.)

So yes, this is under consideration for future API. :slight_smile:

— Itai

On 25 Jul 2017, at 0:44, Morten Bek Ditlevsen via swift-evolution wrote:

In the implementation og JSONEncoder and JSONDecoder we have the internal
functionality that encodes Codable types to a structure that is compatible
with JSONSerialization.
The JSONEncoder then calls JSONSerialization on this structure - and
JSONDecoder vice versa.
In some situations it could be nice to just encode or decode to or from
this structure - and not have the final encoding to Data performed. For
instance if you have some library that hands you a structure in this format
and you would like to perform decoding.

Can anyone else see the relevance of exposing this functionality? It could
be exposed by wrapping _JSONEncoder in a public JSONStructureEncoder or
something similar.

Sincerely,
/morten
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Thank you so much for the comments Itai and David. Makes perfect sense that
the current implementation could be changed in the future. A stream
implementation would be awesome and sounds like it’s perfectly doable.
A future StructureEncoder has my vote. :slight_smile:
Thanks again for the feedback!
Sincerely,
/morten

···

tir. 25. jul. 2017 kl. 21.08 skrev David Hart <david@hartbit.com>:

On 25 Jul 2017, at 18:45, Itai Ferber via swift-evolution < > swift-evolution@swift.org> wrote:

Hi Morten,

This is something we’ve considered adding and may do so in the future —
however, this will require additional API review and will not make it in
time for the Swift 4.0 release.
The usage of JSONSerialization as the serialization backend is a current
implementation detail, and may change in future releases; it would, for
instance, be more efficient to read/write JSON as we encode/decode, instead
of trying to collect the entire object graph before performing the next
step.

As a side note, if this could be pushed even further to allow
encoding/decoding to/from a Stream, it would allow me to use Codable on a
project where I’m parsing JSON files in the hundreds of Mbs. I have no
choice but to use a streaming parser.

We could also introduce something like a general StructureEncoder/
StructureDecoder which performs this conversion, as this might be useful
outside of just JSON. (For instance, PropertyListEncoder/
PropertyListDecoder currently do something similar.)

So yes, this is under consideration for future API. :slight_smile:

— Itai

On 25 Jul 2017, at 0:44, Morten Bek Ditlevsen via swift-evolution wrote:

In the implementation og JSONEncoder and JSONDecoder we have the internal
functionality that encodes Codable types to a structure that is compatible
with JSONSerialization.
The JSONEncoder then calls JSONSerialization on this structure - and
JSONDecoder vice versa.
In some situations it could be nice to just encode or decode to or from
this structure - and not have the final encoding to Data performed. For
instance if you have some library that hands you a structure in this format
and you would like to perform decoding.

Can anyone else see the relevance of exposing this functionality? It could
be exposed by wrapping _JSONEncoder in a public JSONStructureEncoder or
something similar.

Sincerely,
/morten
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Terms of Service

Privacy Policy

Cookie Policy