On Tue, 25 Sep 2012, Reinier Olislagers wrote:
That is indeed another approach that doesn't require specs nor docs.
Unfortunately only available to those that have the keys to kingdom :)
Well, I think that trying to let TSDFDataset conform to certain "SDF"
specs is trying to do some unjustified backfitting.
If conforming to the format that is specified in all existing evidence
is wrong but conforming to some format that is never mentioned at all is
right, I give up.
IMO this is no way to run any serious development effort: don't expect
people to read minds about what was intended if that is not documented,
*especially* in cases like this where any knowledgeable person's obvious
conclusion is the one you don't want them to make.
Also, first accepting patches that explicitly aim for sdf/delimitedtext
compatibility (bug 17285,22213) and then stating the opposite is an
excellent incentive for me to drop everything that's sdfdataset related.
IMHO, it should do fixed format and CSV as indicated by the RFC I posted.
All the rest is nice, but not required from my perspective.
It's not required anymore from my perspective either. I just wanted to
fix sdfdataset so that it does what it says on the tin.
I'd suggest:
1. adding a readme as indicated in my other mail so that users and
developers do not fall into the same trap
Hoho, there is no trap :-)
2. documenting similar unwritten assumptions in other relevant units as
well. Not doing so is a great way to discourage contributors
That is definitely not the intention. See my other mail.
I was frankly surprised by the strong responses I got.
Any assumptions I made were mine, and definitely not the law,
I just gave them as 'historical background', because that is how I perceived
the original question :-)
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
