I, for one, do not think this is a good idea. You are using a starting point of the operating system, which is a mistake in my opinion. The better starting point should be from the standpoint of the function you wish to provide, define the operations that class should provide and implement it in a way that the ooRexx programmer doesn't see a difference. For those types of classes, you should never need to code your program to to select for the operating system (e.g., use one ::requires on windows, a different one for Linux, yet another for the Mac). The class implementation should hide all of that. The underlying implementation might have a source code layout that mimics your hierarchy below, but the ooRexx programmer should never see that. These classes might be delivered as builtin items (such as the new .File class), or provided as separately loaded pieces (e.g., as rxsock is).
That said, there are definitely categories of things that are inherently OS-specific. ooDialog, OLEObject and the windows registry are 3 excellent examples of that. Those subsystems should be clearly segregated from the portable classes and only available by declaring the appropriate dependencies. Rick On Fri, May 7, 2010 at 11:08 AM, David Ashley <david.ashley....@gmail.com> wrote: > ooRexx Operating System Analog Classes > > > The basic premise for these classes is to provide a standardized class > hierarchy to the > operating system environment from generic behaviour to platform specific > behaviour. > The will allow for the logical extension of the class hierarchy in the > future. Hopefully > this will be a good design that will not have to be modified in the > future and thus > will not impact user programs when it is modified or further extended. > > As an example of how the class hierarchy will be constructed we will > create a fictitious > class that is extended from generic to specific behaviour. > > base > | > +----+-----+ > | | > nixbase winbase > | > +----------+----------+ > | | | > macbase linuxbase aixbase > > Additional levels could be added. For instance, if there was a > difference in Windows XP > and Windows 7 then a new level could be added in order to subclass the > winbase class > in order to encapsulate that specific behaviour. I really see this as a > possibility for > the linuxbase class so that differences between distributions or > differences between > GTK and KDE could be expressed. > > Next, we need to come up with the list of basic operating system classes > which will > be extended as shown in the example above. In some cases we may need > multiple levels > prior to the nixbase/winbase level, but we can work that out later. Here > is a partial > list of the basic classes as I see them. > > Memory > Semaphores > Processes/threads > File System > File > Printing > Network > Date/time > Users/groups > > I am sure there will be others, and probably new levels, added to the > list above. > But this should give us a good start to flesh out the details. > > Please let me know if you think this is a good idea or not. I strongly > believe that > a class hierarchy like this will be the key to the future success of > ooRexx. If we > can give equal support to all of our supported platforms and can easily > extend this > hierarchy to support other platforms in the future, then our success will be > guaranteed. > > David Ashley > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
