json struct

[staycoolcall911]

See this discussion.

We want to be explicit about structs that are "serializable" to json by marking them with the json modifier, so it'll be: json struct.

Example:

// Valid:
json struct A {
  a: str;
  b: num;
}

// Invalid:
json struct B {
  a: cloud.Bucket;
  b: num;
}
// ^^^^^^^^ Struct "B" contains field "a" which cannot be represented in Json

[hasanaburayyan]

So im interested in how this implementation would work with structs that are jsii imported? Do we need to specify that they are json structs when we import them?

I wonder, is it not sufficient that we just have compile time errors (which we have now) when you try to call fromJson on a struct that is not json serializable.

[Chriscbr]

@hasanaburayyan

So im interested in how this implementation would work with structs that are jsii imported? Do we need to specify that they are json structs when we import them?

I think when the compiler is importing structs from JSII libraries, we could check whether they're JSON-safe. If a struct type is JSON-safe, then we'll import it with the json flag enabled, treating it as if the user in the JSII library had defined it as json struct in Wing. It would be a backwards compatibility measure.

I wonder, is it not sufficient that we just have compile time errors (which we have now) when you try to call fromJson on a struct that is not json serializable.

Good question, yeah I think it depends on whether this json modifier will provide value by, say, preventing errors.

Here's a question to consider - does changing the fields in a struct (adding, removing, renaming, or changing their types) count as a breaking change in a Wing library?

One possible answer is it depends. If you're removing a field, changing a field, or adding a new required field, the answer is usually "yes" - because anyone using the library now needs to update their code to include the updated field(s). But if you're adding a new field that has an optional type, then it's not a breaking change, since all existing usages of the struct (like struct accesses or creations) will still be valid. I think this is how it works in most JSII languages. Ideally we would like to provide that same kind of benefit in Wing, since structs are used a lot for class constructors.

The issue is if you add a new optional field that is non-Json-serializable, then it's now a breaking change. Because this is serializable:

struct Foo1 {
  a: str;
}

and this is not:

struct Foo2 {
  a: str;
  b: cloud.Bucket?;
}

Put another way: in a world where Wing didn't provide free fromJson methods to every struct, replacing Foo1's fields with Foo2's fields would not be a breaking change -- but in a world where fromJson methods are automatically provided, then it is a breaking change.

By requiring the json keyword, then any change to a struct's json serializability will be decided/consented by the library author. So in my head that's the main reason to add a json struct modifier.

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 90 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!