briand@infmx.UUCP (brian donat) (06/09/90)
The more I look at and work with classes and the objects which are instantiated from them, the more I find myself reminded of a certain similarity (in some cases) between objects and the Unix method of using tools by providing means of linking various tools via pipes, etc.. Is this an appropriate way to view object oriented programming? That is should even main() be likened to an object which contains successivley smaller groupings of objects, each delivering up and back to main(), a larger and larger product, which might finally be output as a result? main() might simply look like: #include "mainobj.h" main() { mainobj seed; exit(seed.quit()); } and then, you might have in mainojb.h, a construct mainobj(argc argv envp) and likewise mainobj(), which define the normal program flow which may have otherwise been written out in main() { }, in procedure oriented style. Of course, this raises some interesting questions like, Can I do a setjmp() and then longjmp() out of a class object and into another? and Can I do an exit() out of some lower level object and still do a halfway decent clean-up as may be necessary with open files etc.. that were opened in objects which operate over and above the object where the exit occurs? How do I handle recursion in a pure object-oriented way? Yep, that much seems obvious. All the major bugaboos would regard program flow-control. So, it would appear that there does exist a threshhold where a programmer is forced to use procedure oriented style. You might be able to define a class object 'X', such that it has methods for maniupulating 'X', but defining class object 'main' is not always possible. Its methods would be limited to constructors and destructors. Still, its nature may preclude it being defined as a pure object. Should 'C++' and other OOP languages allow you to define a special type of class which might be called a 'flow' class? Such a class would allow a degree of hocus-pocus to accomodate procedure-like flow between objects. I mean, what the hell, if we're going to do object-oriented programming, why not go all the way? --infmx!briand@pyramid Funny thing, most of the code would wind up in header files. Maybe there'd be some scoping problems thrown in there too!