brnstnd@stealth.acf.nyu.edu (04/08/90)
In article <DAVIS.90Apr6151002@muscle.pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes: [ what's life, the universe, and everything? ] 42. ANSI C is the C standard settled upon by ANSI; it's generally better than the old language, but most C compilers today don't understand it. > Also what is object oriented programming? The latest name that young urban computer science types have applied to the old idea of adding another level of indirection to function calls. Followups to comp.lang.misc. ---Dan
Chewbacca@cup.portal.com (Paul Frederick Snively) (04/10/90)
brnstnd@stealth.acf.nyu.edu writes: >> Also what is object oriented programming? > >The latest name that young urban computer science types have applied to the >old idea of adding another level of indirection to function calls. At best this definition is grossly naive and misinformed; at worst it is just plain wrong. There doesn't seem to be a "definitive" description of the fundamentals of object-oriented programming, so the best that I can do is to provide you with a list of the things that come to my mind when I happen to think of object- oriented programming: * Encapsulation (the association of data with the procedures that operate on them), whether rigidly enforced or not. * Inheritance (the notion that these combinations of data and procedures can be described as increasing specializations of their ancestors, e.g. an AVL tree might be a specialization of a binary tree, which in turn might be a specialization of a tree, etc. Many object-oriented systems use terms like class, superclass, and subclass to refer to this relationship). * Polymorphism (the notion that I should be able to plug-and-play objects as long as I send them the right message with the right interface, e.g. asking a string object to "print" itself and asking a floating-point object to "print" itself should both work as I expect, regardless of how the "print" mechanism for each of those types does its thing). Object-oriented languages run quite a gamut--everything from the deliberately simplistic Object Pascal to the bordering-on-the-eldritch Common Lisp Object System. Hopefully this is a reasonable introduction to the underlying concepts. Some readers may point out that none of the features of object-oriented programming is impossible to accomplish without using object-oriented programming languages, and of course, they are correct--as usual, the issue is solely one of whether you wish your language to assist you in such architectural trivia or not.
grover@brahmand.Sun.COM (Vinod Grover) (04/10/90)
In article <28742@cup.portal.com> Chewbacca@cup.portal.com (Paul Frederick Snively) writes: >brnstnd@stealth.acf.nyu.edu writes: > >>> Also what is object oriented programming? >> >>The latest name that young urban computer science types have applied to the >>old idea of adding another level of indirection to function calls. > >At best this definition is grossly naive and misinformed; at worst it is just >plain wrong. > >There doesn't seem to be a "definitive" description of the fundamentals of >object-oriented programming, so the best that I can do is to provide you with >a list of the things that come to my mind when I happen to think of object- >oriented programming: > >* Encapsulation (the association of data with the procedures that operate on > them), whether rigidly enforced or not. Who says encapsulation cannot be provided by functions? >* Inheritance (the notion that these combinations of data and procedures can > be described as increasing specializations of their ancestors, e.g. an AVL > tree might be a specialization of a binary tree, which in turn might be a > specialization of a tree, etc. Many object-oriented systems use terms like > class, superclass, and subclass to refer to this relationship). Block structure (lexical scoping in newspeak) can provide some of these too.
rick@tmiuv0.uucp (04/12/90)
In article <28742@cup.portal.com>, Chewbacca@cup.portal.com (Paul Frederick Snively) writes: > brnstnd@stealth.acf.nyu.edu writes: > >>> Also what is object oriented programming? >> >>The latest name that young urban computer science types have applied to the >>old idea of adding another level of indirection to function calls. > > At best this definition is grossly naive and misinformed; at worst it is just > plain wrong. > > There doesn't seem to be a "definitive" description of the fundamentals of > object-oriented programming, so the best that I can do is to provide you with > a list of the things that come to my mind when I happen to think of object- > oriented programming: > [list of items deleted] The best "thumbnail" sketch of OOPS (Object Oriented Programming Systems) I can offer is that your programming style (well, actually your problem solving style) changes. Currently, C causes you to think "procedure-wise". In other words, you think about _how_ to solve the problem, writing a list of procedures that will accomplish the task. This involves how to manipulate the data objects you're playing with at each step of the way. In C++, the OOPS version of C, you think "solution-wise". You simply write code which treats your data objects as though they were standard C variable types. You don't have to worry about "Gee, now, if I want to add these two structures, I have to add each member of one to the corresponding member of the other" and write the code to do that each time. Instead, you simply say "c = a + b", where a, b, and c are the structures you are playing with. Later on, you write a "data abstraction" which defines what the structures look like, a set of functions and operators which perform the operations on the data, and which parts of the structures are visible to the outside world. Once that's done, your code is much more readable, since you're not writing "c.mem1 = a.mem1 + b.mem1;", just "c = a + b". That's simplifying it a bit, but the general idea is correct. C++ can really make some nasty and complex code a heck of a lot easier to deal with. -- .-------------------------------------------------------------------------. / [- O] Rick Stevens (All opinions are mine. Everyone ignores them anyway.) \ | ? +--------------------------------------------------------------------| | V | uunet!zardoz!tmiuv0!rick (<-- Work (ugh!)) | |--------+ uunet!zardoz!xyclone!sysop (<-- Home Unix (better!)) | | uunet!perigrine!ccicpg!conexch!amoeba2!rps2 (<-- Home Amiga (Best!!) | \ 75006.1355@compuserve.com (CIS: 75006,1355) (<-- CI$) / `-------------------------------------------------------------------------' "I bought some instant water, but didn't know what to add." - Steven Wright
davies@sp20.csrd.uiuc.edu (James R. B. Davies) (04/13/90)
In article <539@tmiuv0.uucp>, rick@tmiuv0.uucp writes: |> The best "thumbnail" sketch of OOPS (Object Oriented Programming Systems) I |> can offer is that your programming style (well, actually your problem solving |> style) changes. Currently, C causes you to think "procedure-wise". In other |> words, you think about _how_ to solve the problem, writing a list of procedures |> that will accomplish the task. This involves how to manipulate the data |> objects you're playing with at each step of the way. |> |> In C++, the OOPS version of C, you think "solution-wise". You simply write |> code which treats your data objects as though they were standard C variable |> types. You don't have to worry about "Gee, now, if I want to add these two |> structures, I have to add each member of one to the corresponding member of |> the other" and write the code to do that each time. Instead, you simply say |> "c = a + b", where a, b, and c are the structures you are playing with. Later |> on, you write a "data abstraction" which defines what the structures look like, |> a set of functions and operators which perform the operations on the data, and |> which parts of the structures are visible to the outside world. Once that's |> done, your code is much more readable, since you're not writing "c.mem1 = |> a.mem1 + b.mem1;", just "c = a + b". |> |> That's simplifying it a bit, but the general idea is correct. |> |> C++ can really make some nasty and complex code a heck of a lot easier to deal |> with. |> Well, I for one don't always write the absolute lowest-level inline-est code possible when using ANY language. My first impulse when I want to copy one string to another isn't to think "Gee, now, if I want to copy one string to another, I have to move each byte of the first string to the corresponding byte of the second string" and then write register char *cp1,*cp2; for (cp1=string1,cp2=string2;*cp1;cp1++,cp2++) *cp2 = *cp1; *cp2 = '\0'; Instead I write strcpy(string2,string1); Admittedly, it might be nice to just write string2 = string1; but I'm comfortable with function calls instead of operator overloading. What you're describing used to be called "information hiding" and "modularity" and "reusability" and maybe "functional decomposition" and probably "structured programming". The argument about "C makes you think of methods" versus "C++ makes you think of objects" is a rehash of an old claim by the function-language crowd. I've seen little evidence that it has any validity among trained, experienced programmers - they can write in any language successfully. And, as it has oft been stated, it is possible to write bad code in any language (even C++). All in all, I tend to agree with Mr. Bernstein - the same old stuff using some new words.
) (04/13/90)
Yes, it is possible to write bad code in any language (esp since
C++ will accept C code), and no, it can't FORCE you to think in any
particular style... (a better word would be encourage, but that still
has nothing to do with what I"m about to say).
The first OOPS was Simula... Smalltalk evolved from something that
evolved from Simula.. and thats that.. Simula, as you can sort of tell
from the name, was a language written for creating simulations.
It also happens that the data hiding features of the language are
encouragable things to a "well structured program". The DoD liked the
way it handles object, and had it encorporated into Ada (since Ada is
designed to work with actual systems, having somthing that deals with
actual objects real well is good).
My reason for liking the language is that I *LOVE* C, and happen
to be very interested in simulation work..and C++ gives me a lot of tools
and system features to do things.
An interesting note is that the first C++ compilers didn't output
native code (executable), they output C code... so anything you do in
C++ *can* be done in C...just not so cleanly (it basically checks your
code and does some syntactic modification..
string1 + string2
becomes
string.add(string1,string2)
where string.add is a pointer to a function that adds strings by whatever
your definition of "string addition" is (it also returns whatever you
tell it to).
though, g++ does output executable.
Johnnew@udel.EDU (Darren New) (04/13/90)
In article <1990Apr12.214718.18545@ux1.cso.uiuc.edu> davies@uicsrd.csrd.uiuc.edu writes: >All in all, I tend to agree with Mr. Bernstein - the same old >stuff using some new words. I would like to ask you whether you have done any significant implementation and/or design in an OO language? Like Smalltalk or CLOS? (C++ doesn't really count much because you can just ignore the OO stuff.) I have done large apps in both Smalltalk and C and there is definitely different styles of thinking during the problem solving. Which is better seems to me to depend on what is being designed and implemented. Obviously-linear code is easy to do in C and harder in Smalltalk. Code that "flies around" alot in such a way that it is not clear exactly what will happen next (window systems, say, or simulations) are MUCH easier in Smalltalk. The difference is not in the low end; it's in the initial design and top-level implementation. Copying strings is the same in both. -- Darren
brnstnd@stealth.acf.nyu.edu (04/14/90)
In article <28742@cup.portal.com> Chewbacca@cup.portal.com (Paul Frederick Snively) writes: > brnstnd@stealth.acf.nyu.edu writes: > > > Also what is object oriented programming? > > The latest name that young urban computer science types have applied to the [ obtw, credit to Rod Schmidt for noting the abbreviation ``Yuckies'' ] > > old idea of adding another level of indirection to function calls. > At best this definition is grossly naive and misinformed; at worst it is just > plain wrong. I stand by my definition. For fun I implemented so-called ``strictly type-checked fully polymorphable objects with multiple inheritance'' in C macros a few months ago. From the point of view of the macros, objects were either another level of indirection to both function calls and structure element accesses, or another level of indirection to just function calls, depending whether they were compiled for space or for speed. Followups to comp.lang.misc once again. ---Dan