Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!voder!pyramid!infmx!briand
From: briand@infmx.UUCP (brian donat)
Newsgroups: comp.lang.c++
Subject: `flow' class?
Keywords: getting from here to there purely w. objects
Message-ID: <4452@infmx.UUCP>
Date: 8 Jun 90 18:22:45 GMT
Organization: Informix Software Inc., Menlo Park, CA.
Lines: 67



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!