-
Notifications
You must be signed in to change notification settings - Fork 3
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
fromJson should handle types with disabled default-constructor #12
Comments
If we check the constructor of the type T and see that it takes one argument we could do fromJSON on the type of the argument and then call the constructor on the returned value. |
If I understand you correctly the problem is when the default/empty constructor is disabled? It would be nice to support constructors, but indeed not clear how. Can you get the names of the variables passed to a constructor? Maybe we can map order of variables defines in the constructor to in the class? But not sure if that information is available. struct Point
{
double _x;
double _y;
this( double x, double y ) { _x=x; _y=y; } // Order of x,y line up with order of _x and _y
} |
Yes the problem is when the default constructor is disabled, since we don't try to call other constructors. We can indeed get all overloads of the constructor using __traits(getOverloads,"__ctor"). A first step to solve this would be to use annotations to choose a function/constructor to use, just like Jackson.
We can't do this perfectly without inspecting the whole program, but I want to put in some effort to get the default way really good. I want to make it feel magical. |
The options that I think are correct in most cases (and therefore the most magical) are:
Feel free to ask on the forum what they think. Might also result in some more interest in painlessjson :). Only risk is that it will result in loads of bike shedding. Just choosing a solution and sticking with it might be best. |
As an aside. I only just discovered tupleof, which you can use to cycle over all fields (excluding hidden fields) in order. Guess it ignores @properties |
Just noticed another jsonizer has just been added to code.dlang.org. They do work with non default constructors (and have done some work on subclassing): |
I think jsonizer looks quite good. Is it best to keep working on two separate libraries or should we try to join efforts? |
I guess the forum post made someone realize they had written the same thing and decide to publish it. It would be nice if we were able to merge, but I don't really want to change our API (since people might already be using it) and I think there is room for keeping both around. The licenses should even allow cross pollination. |
Hey, I'm the author of One one hand, On the other hand, it might be interesting to see what we come up with if we keep working separately, and at some point try to combine the best of both implementations. I just want to avoid a situation where someone is torn between two libraries each providing part of what they need. |
Great! |
Hi On Fri, 13 Mar, 2015 at 5:22 PM, Ryan Roden-Corrent
I guess one thing we could try is to develop a general Edwin |
I didn't realize painlessjson did that. If that's true, then it does a better job than jsonizer, which picks arbitrarily if you have more than one valid match. In that case, the only feaure jsonizer supports that painless doesn't is factory construction, which it might be what you're looking for in #8. A few other apparent differences based on the docs:
I'm interested in this -- it definitely feels like most of the work I did related to inspecting types as opposed to actually doing json stuff. cerealed is another project that may be of interest here, and there is probably at least one similar library out there for xml. Two crazy goals I had for jsonizer are serializing delegates and compile-time deserialization (akin to ctini). I'm not sure that anyone actually wants/needs those features, I just want to know if it can be done :) |
I had great help from your code when implementing that feature. It looks quite similiar to your code.
This is a good idea in the long run, but should not be currently prioritized unless you think that's the most fun thing to work on. JSON offers a good starting point and I think the focus should be on improving the serialization parts and not on adding more supported formats.
We will need a solution like mixins to be able to access private fields. At least I am not aware of any possibility to circumvent private access like you can in C++. Perhaps using unsafe pointers and platform specific code which I wouldn't like at all. |
Using https://github.com/Zalastax/zalastaxlibd/blob/master/source/notnull.d to wrap types that shouldn't be null is not supported unless the wrapped type implements _fromJSON.
fromJSON!(NotNull!(int[])) should be possible to call.
I have no idea how this should be implemented in a generic way, but lets discuss some ideas and ask the community if we get stuck.
The text was updated successfully, but these errors were encountered: