Closed GoogleCodeExporter closed 9 years ago
I wouldn't use GetUninitializedObject since it doesn't call the constructor.
The
serializer is based off of public properties and fields and thus doesn't deal
the
private members of the class. Without this it couldn't reliably restore the
instance
to its previously serialized state.
There is also a ConstructorParameter attribute, which I thought I had some docs
on,
but I guess not. You can attach it to a property like this:
public class MyPointConstructor
{
private int _x;
private int _y;
public MyPointConstructor(int x, int y)
{
this._x = x;
this._y = y;
}
[ConstructorParameter(0)]
public int X
{
get { return _x; }
}
[ConstructorParameter(1)]
public int Y
{
get { return _y; }
}
}
When serialized it looks like this:
new "JsonExSerializerTests.Mocks.MyPointConstructor,JsonExSerializerTests"(3, 9)
The Deserializer can accept the constructor syntax without the
ConstructorParameter
attributes and it will try and find the right constructor to call.
You could also create a TypeConverter for the class and ultimately extend the
TypeHandler if necessary.
Original comment by elliott....@gmail.com
on 30 Jul 2008 at 11:28
The ConstructorParameter obviously wouldn't work in a Web scenario, however
I've got
some ideas on how to make that work even with JsonStrictOptions turned out that
I
might put in a future release. The concept would be to go ahead and serialize
the
constructor parameters as normal properties of the class like so:
{
"X":3,
"Y":9
}
On deserialization it would pull them out of the regular property list and use
them
to construct the object.
Original comment by elliott....@gmail.com
on 30 Jul 2008 at 11:32
Hi, thanks for responding. I see your concerns. May be issuing a warning when a
class
with no public constructor gets serialized would be a fine choice then.
Furthermore, I think that it is rather counter-intuitive when
serialization/deserialization does not not work for public classes containing
only
public properties (hoping for some reconsideration). Most of my model
representing
classes are modeled this way.
Regarding the ConstructorParameter(): I would wish some additional features for
it:
a) lookup based on parameter name instead of index, indices just do not mix with
refactoring, naming patterns seem to be more stable.
b) Using feature a), an attribute that uses the 'camel cased' name of the
property to
lookup the constructor parameter (rather esoteric, I know :)
c) Some parameter type / order verification, so that errors are spotted on
serialization instead of deserialization.
And BTW: Thanks for the library, I especially like the graph serialization
feature!
Original comment by paramatrix@gmail.com
on 31 Jul 2008 at 6:36
Original comment by elliott....@gmail.com
on 6 Aug 2008 at 7:08
Constructor parameters are now serialized as properties. They are
automatically
pulled out of the property list upon deserialization to be used to construct
the
object. They can also be specified by name now.
Original comment by elliott....@gmail.com
on 26 Jan 2009 at 1:00
3.0 Release
Original comment by elliott....@gmail.com
on 26 Jan 2009 at 2:22
Original issue reported on code.google.com by
paramatrix@gmail.com
on 29 Jul 2008 at 1:19