Please, don't get caught up in my failure to provide a clean
representation of the API, the more reasoning for how we are
doing things the better the documentation.
On Tuesday, 11 June 2013 at 17:33:59 UTC, Jonathan M Davis wrote:
If you can't create a pull reuest from what you have,
then the API isn't ready.
I am already aware this is your opinion. I'm looking for the
correlation of being able create a pull request and an API being
ready.
It needs to be laid out in a manner that we can see what the
actual API would be if it were merged into Phobos.
Exactly as it is present, the only problem I see is that several
helper packages exist and their documentation is present. Look
again at the package list:
https://dl.dropboxusercontent.com/u/18386187/orange_docs/Serializer.html
Now collapse core, util, and xml. Please point out to me, what of
that does not look ready for inclusion into Phobos?
Is it because "orange" is the top package and not std?
Is it because there are 7 modules and 2 packages?
Is it because the docs were generated with CandyDoc?
I realize at this point that having documentation for the
supporting libraries was a mistake, I'm now looking for concrete
examples of why this would have been an issue if they had been
hidden to begin with, or is this purely a principled stance?
Another piece of information I'm interested in, is your adamant
request for a pull request-able code for the internal code
review. Meaning as a Phobos maintainer you can see how the
supporting libraries are stored? Or are you concerned that the
public API will need to change for a 3rd party library to fit
into Phobos?
