Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serialising anonymous/immutable types #68

Closed
drewnoakes opened this issue Feb 24, 2015 · 6 comments
Closed

Serialising anonymous/immutable types #68

drewnoakes opened this issue Feb 24, 2015 · 6 comments
Labels
enhancement Requires or request to feature enhancement
Milestone

Comments

@drewnoakes
Copy link
Contributor

Is it possible to serialise an anonymous type?

For example:

new { Foo = 1, Bar = "Hello" }

This would be very useful for us.

Unfortunately, GetSerializer<T> doesn't seem to work, presumably as the properties of anonymous types are read only. Because the returned serializer can both serialise and deserialise, it's not possible to build it. However we only need the serialiser bit.

(cc @lufka)

@yfakariya
Copy link
Member

In my unstanding, anon types cannot be take away from declaring method, so I cannot imagine use case when anon type serialization is really useful. Would you tell me when and how do you use anon types serialization?

@drewnoakes
Copy link
Contributor Author

Anonymous classes are regular classes and their type can be known and passed around. This is especially easy when using generic methods:

public void Log<T>(LogLevel level, T data)
{
    _serializationContext.GetSerializer<T>()
        .Pack(_logStream, new { Level = level, Data = data });
}

That's actually pretty close to our use case. The logging API should support arbitrary data from users, so long as it only contains serialisable types. However the anonymous type simply isn't serialisable.

The problem seems to be that msgpack-cli uses one set of restrictions across both encodable/decodable types. This means types must always have read/write properties in order to work with the lib. This seems like a significant limitation, especially when you use immutability extensively in your code.

Of course it's not limited to anonymous types:

public class Foo { public string Name { get; private set; } /*...*/ }

_serializationContext.GetSerializer<Foo>() // bang!

In this case, as with anonymous types, Foo is definitely serialisable, however it is not deserialisable. If There is definitely a strong use-case for treating serialiser and deserialiser types separately.

@drewnoakes drewnoakes changed the title Serialising anonymous types Serialising anonymous/immutable types Mar 2, 2015
@yfakariya
Copy link
Member

Thank you for great suggestion. I understand that there are use cases that need 'asymmetric' serializer which only available for serialization or deserialization. Although I'm interested in asymmetric serializers feature, I cannot tuckle to it soon because I'm working on another issue.

@yfakariya yfakariya added the enhancement Requires or request to feature enhancement label Mar 2, 2015
@drewnoakes
Copy link
Contributor Author

This would certainly be very useful for us. I'm not sure how hard it would be to retrofit this to the current API. I suppose the current serialiser objects could implement both IPacker<T> and IUnpacker<T> or something like that, and then it would also be possible to generate just one or the other:

_serializationContext.GetPacker<Foo>().Pack(new Foo()); // ok

_serializationContext.GetUnpacker<Foo>().Unpack(new Foo()); // bang!

@yfakariya yfakariya added this to the 0.7.0 milestone Dec 23, 2015
@yfakariya yfakariya modified the milestones: future, 0.7.0 Jul 24, 2016
@yfakariya yfakariya modified the milestones: 0.9, future Sep 22, 2016
yfakariya added a commit that referenced this issue Sep 23, 2016
This commit relaxes serialization target retrieval, so it allows 'asymmetric'(pack only) serializer generation.

* This commit also adds unit tests.
* Unpack only serializer is not supported yet because there are no patterns found which can be deserialize but cannot be serialize.
* Supporting capabilities is needed to distingush pack only serializers from normal serializers.
@yfakariya
Copy link
Member

This was implemented in 0.9.

@drewnoakes
Copy link
Contributor Author

Great news!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Requires or request to feature enhancement
Projects
None yet
Development

No branches or pull requests

2 participants