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.