On 2013-06-11 02:47, Jonathan M Davis wrote:

> I thought that it was clear that anything being submitted for review for
> inclusion in Phobos actually had to be in a state where a pull request for
> Phobos could be created for it. We certainly can't possibly vote it in if it's
> not in such a state, because we wouldn't even know what it would look like
> when it was merged in.

A quick answer:

* orange.serialization.Events -> std.serialization.events
* orange.serialization.RegisterWrapper -> std.serialization.registerwrapper
* orange.serialization.Serializable -> std.serialization.serializable
* orange.serialization.SerializationException -> std.serialization.serializationexception
* orange.serialization.Serializer -> std.serialization.serializer
* orange.serialization.archives.Archive -> std.serialization.archives.archive
* orange.serialization.archives.XmlArchive -> orange.serialization.archives.xmlarchive
* orange.xml.PhobosXml -> (merge with) std.xml

The rest I'm not sure about. I can put it in std.traits and other places where I see it fit.

I'll start with merging it with Phobos.

-- 
/Jacob Carlborg

On 2013-06-11 04:46, Steven Schveighoffer wrote:

> "Just imagine what the API would be like if it was in Phobos" isn't good
> enough.  Especially for this library, it looks like there are quite a
> few modules.  Where do those go?  What changes are made?  Standing out
> right away is
>
> We need an API document of what it would be in Phobos, and how the API
> works.
>
> I would recommend suspending this review, putting together a strawman
> API of how you think it will look under phobos, post that as an RFC, and
> then judge whether it's worth porting from that response.  If there's
> only a subset of the API we should be looking at that, show me that subset.
>
> We simply cannot have a formal review on software that isn't ready for
> inclusion - by definition we would have to have another review later
> when it's ready for inclusion.

The API is ready, see my post to Jonathan.

http://forum.dlang.org/thread/adyanbsdsxsfdpvoozne@forum.dlang.org?page=2#post-kp6gi4:242tvc:241:40digitalmars.com

-- 
/Jacob Carlborg

On 2013-06-11 05:48, Steven Schveighoffer wrote:

> So where is the API?  The link you posted is not ready to be part of
> Phobos, and there is no clear indication of how it will reside in Phobos.
>
> Please make that clear.

See my previous post:

http://forum.dlang.org/thread/adyanbsdsxsfdpvoozne@forum.dlang.org?page=2#post-kp6gi4:242tvc:241:40digitalmars.com

The utility functions are less important.

-- 
/Jacob Carlborg

>> IMHO I think the tests would fit nicely into the package itself. Close
>> to the code it tests.
>
> Do you mean in package.d? Yes, if that's possible.

Actually I was thinking about just moving the test dir into the std.serialization. It shouldn't be part of the final distribution of course so the Makefiles would have to take that into consideration.

/Jonas

I really think that all the general stuff in the utils/core etc. packages should be merged into phobos as the very first thing and as normal pull requests to phobos. They are not serialization specific and rather small additions.

After that the std.serialization part could go through normal review and would simpler to review.

/Jonas

On 6/11/13 2:36 AM, Jacob Carlborg wrote:
> I'll start with merging it with Phobos.

If that's the case I suggest we suspend the voting process to be fair to the submitter (allow time to integrate feedback etc).

Andrei

11-Jun-2013 13:00, Jonas Drewsen пишет:
> I really think that all the general stuff in the utils/core etc.
> packages should be merged into phobos as the very first thing and as
> normal pull requests to phobos. They are not serialization specific and
> rather small additions.
>
> After that the std.serialization part could go through normal review and
> would simpler to review.
>
> /Jonas

Rather what we usually do with helpers of unknown utility etc. is to keep them package/private for now and let their fate be decided separately via normal pull request process.

The fact that we have no good idea where to put (if at all) an internal primitive should not (I'd say must not) postpone or undermine the review of the module/package itself.
-- 
Dmitry Olshansky

On Tuesday, 11 June 2013 at 12:22:28 UTC, Andrei Alexandrescu wrote:
> On 6/11/13 2:36 AM, Jacob Carlborg wrote:
>> I'll start with merging it with Phobos.
>
> If that's the case I suggest we suspend the voting process to be fair to the submitter (allow time to integrate feedback etc).
>
> Andrei

I have suspended the review.

Jabob, please take all supporting libraries and hide them from the public API since if you guess wrong the review well be even less likely to be about a serialization library.

On Tuesday, 11 June 2013 at 03:36:23 UTC, Jonathan M Davis wrote:
> The whole _point_ of an official review is to review the API that would end up in Phobos (the implementation is also important but very much secondary).

Then what are you complaining about?

> If a submission's API isn't ready to be merged into Phobos assuming that it passed the vote, then it isn't ready for review.

The whole point of an official review is to decided if the API is ready to be merged into Phobos. A review manager can't make that decision, he brings it to the community and has them decided, "Is this API what we would like to see for handling ____?" and the community votes yes or no.

Phobos is lacking in functionality to support Jabob's submission. I think it is wrong to require that Phobos be fixed prior to a formal review. Since Steven brought up the API your taking issue with that, but I'm wondering about the Phobos maintainers views on the implementation details not being ready for Phobos.

I don't think an addition passing votes means that it must be included into Phobos right away (we don't have std.uni due to a failed test on BSD). As long as there is agreement on direction, for example it should use std.xml when we actually have a replacement for it, then things should be fine. And if there are many changes needed then a vote can be postponed until after the changes are complete and a review wouldn't be needed again unless the API changed.

On 2013-06-11 15:36, Jesse Phillips wrote:

> I have suspended the review.
>
> Jabob, please take all supporting libraries and hide them from the
> public API since if you guess wrong the review well be even less likely
> to be about a serialization library.

I'll do that.

-- 
/Jacob Carlborg