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!