On 2013-02-15 18:20, Andrei Alexandrescu wrote:
Here's what I think - in order to add things to Phobos and generally the standard distribution you must revamp your entire attitude.
Sure I may not have had the best attitude in this discussion. But that has nothing to do with me trying to get Orange into Phobos several years ago.
I have a lot of sympathy because years ago I was in the exact position. I'd written the Loki library for C++ that included many components deserving inclusion in C++'s standard library. As a first step I asked for Loki to be included in Boost. The attempt was met with interest but it soon became obvious that I'd need to go through a difficult review and make quite extensive adaptations and changes to the library in order to be considered. My attitude was "take it or leave it" and that just didn't work (and in retrospect, for the better).
Part of the proposal was a policy-based smart pointer that was superior in every way I could think of to other candidates. Yet the proposers of those candidates were willing to go through the hard work of improving and streamlining their proposals, to the point they got into Boost and ultimately into the standard. With time the relative deficiencies of that proposal was reduced by adding more kinds of smart pointers, so in the end it all got where it is today. In contrast, I was busy with my Ph.D. research so I didn't have the time to file away all rough edges. That was a good lesson to learn. Applied to the situation of today, to get anything into the D programming language requires determination, humility, and willingness to take criticism and convert it positively. I think assuming that Orbit is a great finalized design that others fail to appreciate is definitely the wrong starting point. The right starting point is asking for feedback, integrate it, and ask again, all in a loop.
Well lucky you. I haven't even got a proper review for Orange. I got some comments and feedback but no formal review. Saying something that I don't want to change anything is plain wrong. I got feedback that slices weren't properly deserialized and that it could be problems if the serializer was templated on the archive. That caused me to completely refactor the library, mostly internal.
I also got the suggestion to allow to set a serializer for a type both for a given instance of the serializer and globally. This also got implemented.
The only thing I haven't implemented that got suggested is support for versions. I haven't done that because I think that this doesn't need direct support because that can be handled by performing custom serialization of a type.
The only thing that could have caused problem is that it also supports D1/Tango. But I have said from day one that if it gets accepted I will remove any traces of D1 and Tango. Most of the code is completely independent of D1/Tango and the code which has dependencies is very local that has nothing to do with the actual design of the serializer.
About Orbit. I started this thread to try and estimated the cost of refactoring Orbit to fit into Phobos/the D distribution. I started with a list, "this is what Orbit uses that does not exist in Phobos. What can we move to Phobos and what cannot be moved to Phobos. What can we do about the rest.". Then the discussion turned into something else.
-- /Jacob Carlborg
