On 24-9-2012 20:21, Michael Van Canneyt wrote:
> On Mon, 24 Sep 2012, Ludo Brands wrote:
>>>> That is in contradiction with the existing implementation
>>> as well as
>>>> the following comments following comments in SDFData.pp
>>>>
>>>> 14/Ago/01 Version 2.00 (Orlando Arrocha)
>>>> John Dung Nguyen showed me how to make this
>>> compatible with
>>>
>>> You are erroneously assuming I actually read the comments.
>>
>> No specs, no docs, only code and comments to go by.
>>
>>>> Is fpc promoting version 77 of the sdf definition?
>>>
>>> I added TSDFDataset to FPC because it added an implementation of CSV
>>> and fixed format data, because this is how I had used them.
>>> That's all I cared about. I had never heard of SDF as a data
>>> format. At the time, I probably assumed SDF were the initials
>>> of the author or so.
>>>
>>
>> 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
2. documenting similar unwritten assumptions in other relevant units as
well. Not doing so is a great way to discourage contributors
3. dealing with issues 22894, 22882 as you see fit
Reinier
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
