Ok, I am going to stick my neck WWAAAAAYY out and put my US 2 cents worth in for any one to flame who want to. Be warned, All return flames will be ignored by me as this is my opinion.
I have been writing Rexx extension libraries since 1990 on multiple platforms like OS/2, Windows, Linux, etc. I have probably written at least 12 different libraries in that period. Some of the libraries have been simple and small but others have been extremely large and very complex. While I agree with Mark that the ANSI Standard Rexx API is at least common across multiple platforms what I want to say is that I consider that API to be some of the worst interface design I have ever seen. It violates so many rules of good design that it is hard to list them all, but I will try to list the worst cases. 1. Forcing the programmer to create Rexx variable names in order to return multiple values from an API call is absolutely bad design. It can cause unforseen problems years after the library has been considered stable by a Rexx programmer who uses the library. I can not tell you how many times I have seen this this pop up over the years, especially when the Library programmer picks the variable names with no input from the Rexx user/programmer. 2. In many cases the single threaded nature of the variable pool interface cause huge problems. In the API only the thread that creates the variable pool can have access to it, thus forcing a Library design that can be clunky at best. In a multi-threaded design you almost always have to resort to using a queue mechanism to work around this and it almost always forces a Rexx program to run single threaded so that you do not create multiple variable pools. 3. Pointers and other binary values always had to be converted to strings. When you do this you lose the context of the data. Yes it is a string, but what kind of data does it hold? Do I perform binary arithmetic on the data or some other kind of arithmetic? 4. The API queuing mechanism again depends on a name that can cause name collision on a system. These four items are my pet peeves with the ANSI Rexx API Standard. If ever an API should have been redone a long time ago this one would be my top candidate. It is a terrible API and no one will ever convince me that the only reason it was adopted was because IBM created it and therefore it already existed, bad as it was. The real problem here is that no one has stood up and cried foul and even if they did there is no active Rexx community who would/could create/approve a new standard. David Ashley ooRexx Development Team ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
