briand@infmx.UUCP (brian donat) (05/02/90)
Has anybody out there considered what a Unix Manual Page might
contain, regarding C++ Objects?
For example, one might suppose that it might be valuable
to list on such pages
The entire object declaration and any declarations
for objects which are 'base' to it.
Explanations of chained functions, etc.
Intended Usage.
Explanation of any algorithms built around the object.
etc.
I pre-suppose that the day'll come when Unix might contain a
standard object liabrary which would be used as readily and
easily as the procedure-oriented functions extant today.
--briandrandy@uokmax.uucp (Longshot) (05/03/90)
In article <4131@infmx.UUCP> briand@infmx.UUCP (brian donat) writes:
-
-Has anybody out there considered what a Unix Manual Page might
-contain, regarding C++ Objects?
-
- For example, one might suppose that it might be valuable
- to list on such pages
-
- The entire object declaration and any declarations
- for objects which are 'base' to it.
-
I disagree. Part of the reasoning behind data abstraction is the lack of
necessity for such knowledge. It's interface should be known-- any accessible
instance variables and methods. Private variables and methods should stay
that way.
Randy
--
Randy J. Ray University of Oklahoma, Norman Campus (405)/325-5370
!chinet!uokmax!randy randy@uokmax.uucp randy@uokmax.ecn.uoknor.edu
"He's not afraid of the judgement. He knows of horrors worse than your Hell."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~briand@infmx.UUCP (brian donat) (05/04/90)
In article <1990May2.232432.11847@uokmax.uucp>, randy@uokmax.uucp (Longshot) writes: > In article <4131@infmx.UUCP> briand@infmx.UUCP (brian donat) writes: > - > -Has anybody out there considered what a Unix Manual Page might > -contain, regarding C++ Objects? > - > - For example, one might suppose that it might be valuable > - to list on such pages > - > - The entire object declaration and any declarations > - for objects which are 'base' to it. > - > > I disagree. Part of the reasoning behind data abstraction is the lack of > necessity for such knowledge. It's interface should be known-- any accessible > instance variables and methods. Private variables and methods should stay > that way. > I agree with you 100%. The reasoning behind data abstraction is to 'hide' implementation details from the 'user' of the object. Much of the literature uses the term 'client' of the object. But you know, I have a little trouble believing that a MAN page would be of optimum use if all it detailed were the function prototypes and the public portions of the class definitions. There's a lot of info particular to classes that's private, but is usefull to know about when coding with those classes. One of the things I've come to note about OOP is that there's a lot copying of code and data going on, as part of language implementation. I consider it very healthy, to know what's being dealt with in this sense. The developer of code should be astutely aware of what is being incorporated into his code. Hence, I might suggest that one takes a practical look at data-hiding. In my mind it was not meant to 'keep secret' implementation details, but to restrict access. Given this distinction, the entire class definition might well be given in MAN pages. Writers of C++ code using such classes should 'know' what they are dealing with, explicitly. This would inevitably help them make sound coding decisions regarding abstract classes. But, lets look at it from the function() abstraction viewpoint. Everything that goes on within a function is not stated in MAN pages, ie. we are not provided with source for the function, only its inputs and outputs via globals, parameters, and return values, and a statement describing its abstract usage are detailed. In that sense, you could be right. Implementation detail rightfully does not belong in MAN pages. My argument that a programmer should be aware of class internals beyond the 'interface' doesn't hold much water when even now, implementation details are 'hidden' with functions in procedure oriented programming. Consider for example, the efficiency differences between fread() and read(). Abstractly, they do the same thing, and on the surface, we are only aware that there is a difference in the interface parameter types (file handles vs. file pointers). Of course, we take the time to learn kernel detail (some of us) and understand the difference in performance and still make coding decisions based on this. But still, there seems to be more room for stretching performance, especially regarding the possible sizes of inline functions, conversions requiring copying, etc., with objects. While the goal is to write easily maintainable and re-usable code, sometimes this goal might be purposely (to some extent) suplanted in favor of specificity for efficiency in terms of speed, and resource usage. These are of course, traditional objectives of software engineering and I'm admittedly in a cloud of greyness, when it comes to considering how OOP relates to maintaining programming goals related to runtime efficiency issues. From what I can see so far, my impression is that OOP sacrifices in these areas to achieve reductions in maintenance costs and perhaps coding costs. Where's the happy medium? When coding, do we go top-down some of the time, bottom-up some other time, or perhaps instead, extremities-in? And then still, there's those '.*' and '->*' operators. What the heck was the reasoning for these, with regard to data members? I can see why they'd be handy for function members. But otherwise, they seem to trash the whole notion of data-hiding and require an intimate internal knowledge of data-members to even be useful. --briand ps. Being new to OOP and C++, I'm still not certain that base objects, compiled and stored as object modules in some library someplace are totally independent of any need for 'meddling' by a programmer. Are the header files that might contain objects going to be available in these libraries, or just the compiled object code??