Thanks guys,
I will commit part 1 now.
Jon
On 13 December 2010 21:41, David Ashley <[email protected]> wrote:
> Never commit anything to a re;leases subdirectory. Your changes should go
> in main/releases/trunk/extensions/csvStream/csvStream.cls.
>
> David Ashley
>
>
> On 12/13/2010 03:33 PM, Sahananda (Jon) Wolfers 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.
>
> 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.
>
> 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.
>
> 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?
>
> 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
> [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
>
>
------------------------------------------------------------------------------
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
