Unfortunately I don't have the bandwidth to participate fully in this discussion this week. Maybe we can bring it up again in a couple of weeks, after getting it started now.
One statement of Rick's is really basic to my thinking though: "I personally think that adding stuff to rexxutil should be the last choice and new functions should be added using" <something other than rexxutil.> The text in the brackets is mine of course. So, what I really wanted to get started is that, I think, we should back David's *nix work from the incubator out of rexxutil and put it <somewhere> else. I didn't want to see a lot more work put into rexxutil in relation to the *nix stuff recently added, if the decision is to back it out. Rick said: "I think it would be a good idea to freeze rexxutil and not use that as a delivery vehicle for any new functions." That's what I want at this point also, but frozen at the point before David moved the *nix functions in. <grin> Once we do a release, it would be too late to take them out. Since, we're not going to do a new feature release in the immediate future, we don't have a problem yet. Also from Rick: "As such, the unix utilities should be in an appropriately segregated library. The big advantage is doing this is getting an immediate error indication when attempting to run the program on the wrong platform." Getting an immediate error, is a big advantage. With rexxutil, you don't know there is a problem until the function is actually used. As for fixing rexxutil, we are pretty limited there. We can't really take anything out. Where Rick and I disagree is, I would like to see the functions (some of the functions) already in rexxutil, that are not currently cross-platform, that could be cross-platform fixed, to be cross platform. But, I do agree that future work is better done by using smaller libraries of related function, implemented through platform independent classes, rather than functions. Like the File class in 4.1. -- Mark Miesfeld ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
