Does this work for "private" fields?

[HerrNiklasRaab]

Hello Alexander,

at first, I am so grateful, that someone developed a JSON mapper, without this awful boilerplate code. Those mixins and abstract just for serialization is a step back and by far no innovation. So thank you!

So to my problem: I have a lot of classes like the one below. The problem is, those are my business objects, so I need a serializer, who can also serialize private fields. As I looked in the source code of dart-json-mapper this feature seems not to exist right now. Of course, I only want to use the serializer in the same library. Otherwise, we wouldn't have access to them.

Would be great to have this, because this is a dealbreaker for me, and should be easy to set up. At least as an option.

class User extends Model implements IImmutableUser {
  String _email;

  String get email => _email; // Here happens, more business stuff in general.
  set email(String email) => _email = email; // Here happens, more business stuff in general.
}

Hopefully we find a solution on this :).

Thanks,

Niklas

[k-paxian]

This one nailed down as well, please feel free to raise more cases.

[HerrNiklasRaab]

Ok, I started working with this one, but I struggle a little bit.

@jsonSerializable
class MockModel extends Model {
  String _email;

  @JsonProperty(ignore: true)
  String get email => _email;
  @JsonProperty(ignore: true)
  set email(String email) => _email = email;
}

I want to serialize and deserialize objects from the class above. Only the private field _email should be a JSON Property. But the JSON I get has no Entry, for the _email field.

Do I need to mark this private field with some annotation class, to get it serialized?

Thanks,

Niklas

[k-paxian]

@HerrNiklasRaab

Don't really understand what are you trying to achieve?

• @JsonProperty(ignore: true) will exclude 'email' property from serialization/deserialization process.
• Private fields cannot be used for serialization/deserialization process by definition, because it is not possible to set value to the private class field w/o corresponding setter.
• By "property" we understand (getter & setter) or public field.
• If you'll like to see different cases like: "only getter w/o setter" - this could be used only for serialization process and can't be used to deserialize that private property.

Please justify your need a bit more clear with the full use case example

[HerrNiklasRaab]

Ok, I didn't know that:

Private fields cannot be used for serialization/deserialization process by definition, because it is not possible to set a value to the private class field w/o corresponding setter.

I am coming from the .NET side, where something like serializing a private field was always possible: https://www.newtonsoft.com/json/help/html/SerializationGuide.htm

• My perspective is, that serialization and deserialization is the process of saving an object and recovering the state of that object at a later point. But when you use properties for serialization, the serialization/deserialization process can change the state of the object, because these getters and setters can contain state changing logic and during serialization/deserialization you are accessing them.

• Secondly, you are forced to make properties public only for the purpose of serialization/deserialization, but probably you don't want to expose this data. This violates the encapsulation of the objects.

On the reflectable Github page they are saying following :

Several parts of the library have not yet been implemented. In particular, the following parts are still incomplete:

• [...]

• Private declarations. There is currently almost no support for reflection on private declarations, as this would require special support from the runtime for accessing private names from other libraries. As an example of a case where there is some support, library mirrors can deliver class mirrors for private classes, and instanceMembers includes public members inherited from private superclasses. But in the vast majority of situations, private declarations are not supported.

So probably we can discuss, this again when reflection for private declarations landed.

Cheers,

Niklas

[k-paxian]

Sounds like a plan!