Here is a perfect example of the kinds of class structure problems I am trying to get defined.
Lets define a process class that also includes thread information. There are 3 OS APIs involved. getpid getppid gettid Lets say we want to define a generic class first and then subclass that as needed. The first thing we discover is that Windows has no easy way to give us the ppid or tid information. Those APIs are not exposed on Windows. Ok, sounds like we need a unix subclass for those two and we just leave them out of the generic class. Now lets take getpid. It turns out that Windows has deprecated this API and now recommends using _getpid instead (for very legitimate reasons it turns out). Also, the include file that defines this API in Windows is process.h, not the same as needed in all *nix versions. So now the question becomes do we build one function with compile time macros to determine what include file and API to use? Or do we build one for *nix and one for Windows? And remember, we just have one API which seems total overkill to put into a library all by itself. Next questions. Do we define dummy methods for getppid and gettid for the Windows specific class? Do we even define a Windows specific class? These are the kinds of problems I am trying to define and create practical solutions for. If we build this kind of class hierarchy for other function sets then the programmer needs to understand how to construct the classes and how define them in a manner that matches other function sets. Just adding subclasses willy-nilly when we need them will lead to the kind of problems that Java is going through today - too many classes and no organization that can be recognized. David Ashley ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
