On Mon, Dec 13, 2010 at 4:33 PM, Sahananda (Jon) Wolfers <[email protected]> wrote: > Hi All, > > following on from a presentation of the ooRexx csvStream class at the > symposium today I have made and am contemplating making some changes. > > It was requested that headered csv files should accept data encapsulated in > directory objects as well as arrays and tables, and I have changed a few > lines to accommodate that. > > Whilst testing those changes I found a bug in the class where if you open a > file that already exists with the write replace mode and with headers, then > it erroneously retained the old headers. > I have coded a fix for that as well. > > I am not sure where I should now commit my changes to. > > Should it be: main/trunk/extensions/csvStream/csvStream.cls or > main/releases/4.1.0/trunk/extensions/csvStream/csvStream.cls? > I notice there are also a couple of copies in peoples sandboxes.
The changes should go to trunk. Once a tree has been moved to releases, that branch is NEVER modified. It is a permanent, read-only record of the code that was used to create the release in question. > > I have also been asked (or perhaps suggested) that csvStream should indicate > if there is badly formed csv data in a file that is being read, and also I > feel that it would be good if I could remove the requirement that csvStreams > be OPENed and CLOSEd explicitly. > > Checking and reporting the bad data seems a bit tricky. Assuming that I > work out how to detect badly formed CSV files, I could then get the class to > report its state as ERROR:. This would require subclassing the state method > and the query method, and I feel unsure that it is the correct way to go as > I feel that I should perhaps return more information such as the nature and > location of the error. This seems like a reasonable way of approaching this. > > As for the requirement to open and close CSVStreams explicitly, that also > seems tricky. I can get the CSVLineIn & CSVLineOut methods to check that > the CSVStream is open and open it if need be. The problem comes with > closing it. The CSVStream must be closed, as otherwise the header > information will not be written back to it. I seem to remember Rick saying > that one cannot always rely on the uninit method being run, otherwise I > could put a check in there and close the Stream if necessary. uninit is not 100% reliable, but it's also really your best option. > > Does anyone have any opinions or guidance on this? > > I think when there are several changes to make, it is better to do a change, > commit, do another change, commit and so on rather than saving them up and > committing them all at once. Is that right? Commit early and often :-) Rick > > Many thanks, > > Jon > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
