On Monday, 12 August 2013 at 13:27:45 UTC, Dicebot wrote:
Stepping up to act as a Review Manager for Jacob Carlborg std.serialization

---- Input ----

Code: https://github.com/jacob-carlborg/phobos/tree/serialization

Documentation: https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/index.html

Previous review thread: http://forum.dlang.org/thread/adyanbsdsxsfdpvoo...@forum.dlang.org

---- Changes since last review ----

- Sources has been integrated into Phobos source tree
- DDOC documentation has been provided in a form it should look like on dlang.org - Most utility functions/template code depends on have been inlined. Remaining `package` utility modules:
    * std.serialization.archives.xmldocument
    * std.serialization.attribute
    * std.serialization.registerwrapper

---- Information for reviewers ----

Goal of this thread is to detect if there are any outstanding issues that need to fixed before formal "yes"/"no" voting happens. If no critical objections will arise, voting will begin starting with a next week.

Please take this seriously: "If you identify problems along the way, please note if they are minor, serious, or showstoppers." (http://wiki.dlang.org/Review/Process). This information later will be used to determine if library is ready for voting.

If there are any frequent Phobos contributors / core developers please pay extra attention to submission code style and fitting into overall Phobos guidelines and structure.

-------------------------------------

Let the thread begin.

Jacob, it is probably worth creating a pull request with latest rebased version of your proposal to simplify getting a quick overview of changes. Also please tell if there is anything you want/need to implement before merging.

OK, time to make a short summary.

There have been mentioned several issues / improvement possibilities. I don't think they prevent voting and it is up to Jacob to decide what he want to incorporate from it.

However, there are two things that do matter in my opinion - pre-UDA part of API and uncertainty about range-based lazy approach. Important thing here is that while library can be included with plenty of features lacking we can't really afford to break its API only few releases later just to add/remove these features.

So as a review manager, I think voting should be delayed until API is ready to address lazy range-based work model. No actual implementation is required but

1) it should be possible to do it later without breaking user code
2) library should not make an assumption about implementation being lazy or eager

That is my understanding based on current knowledge of Phobos modules, please correct me if I am wrong.

Jacob, please tell if you have any objections or, if this decision sounds reasonable - just contact me via e-mail when you will find std.serialization suitable for final voting. I think it is pretty clear that package itself is considered useful and welcome to Phobos.

Reply via email to