473,320 Members | 1,916 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Correct C++ tutorial chapter 2.1 "Classes" available (Windows, mingw/msvc/std)

The eighth chapter (chapter 2.1) of my attempted Correct C++ tutorial is now
available, although for now only in Word format -- comments welcome!

Use the free & system-independent Open Office if you don't have Word.

Classes
<url: http://home.no.net/dubjai/win32cpptut/w32cpptut_02_01.zip>

Introduces the C++ language feature used to define new types, namely
classes. The focus in on creating safe and reusable classes. As a main
theme the jugs-puzzle program from chapter 1.4 is revisited, and the
chapter ends with an example program that solves the puzzle.

General URL:

<url: http://home.no.net/dubjai/win32cpptut/html/>

which provides chapters 1.1 and 1.2 as web-pages (HTML) in addition to the
original Word documents of all chapters in zipped format.

Contents, chapter 2.1:

1 [Background:] PODs, aggregates and pure C++ classes.
2 Classify and define general object member routines.
3 Place inline routine definitions in header files.
4 Design i/o-free classes.
5 Adjust a class to support ease of use, I.
6 Refactor user interface code as a class (class as module).
7 Make a class almost foolproof wrt. access to members.
8 Take charge of per-instance initialization with constructors.
9 Prevent implicit conversions by using explicit constructors.
10 Adjust a class to support ease of use, II.
11 Default constructors & the constructor call guarantee.
12 Use constructor initializer lists to initialize members.
13 A complete example of using classes in a program.

As before, the point of inviting comments is to _fix_ anything incorrect, or
the presentation, or whatever; your input is valuable, and you can thereby
help those who stumble across this tutorial and use it to learn C++.

Thanks in advance,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #1
24 2513
Alf P. Steinbach wrote:
[snip]
Contents, chapter 2.1:


I think a general "motivation" behind the REASONS to WHY the world
evolved into OOP instead of functional programming is lacking.
A big point in the whole OO motivation the way I see it (some people
will say it's a motivation behind only C++, I'd say OO) is typesafety!
(That's why C++ is THE best OO language even though lacking several big
OO features...)

If you encapsulate the function "wag()" in the class "DogTail" you
don't run the risc of of wagging() the Dog!
Or said in plain English, if you don't have typesafety you can run the
risc of trying to fly() a Submarine...

Another objective behind classes the way I see it is encapsulation and
datahiding.

Might be I've missed out several good points here, but my point is that
you should first MOTIVATE your readers before trying to teach them
something new which will seem unnessecary for them to spend time on at
first...

Also I'd stress the private keyword to a much bigger extend, after all
if the private data wasn't around in classes there would be no point in
having classes since the whole idea is encapsulating the functions
together with the data meaning that every operation possible for X
resides inside X which means you can easily see the X's interface and
easily spot all potential problem areas of X (X's public data and
functions)

I'd like to have a header called "The problem" and another called
"Encapsulation and private as your biggest friend" or something...

After all, classes are not about what you CAN do, they're about what
you CAN NOT do!!

Apart from that as usual off course excellent work Alf!

Btw, I'm still waiting for an answer regarding if I can mirror your
tutorials on the SmartWin website...

Thomas Hansen
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #2
* Thomas Hansen:
Alf P. Steinbach wrote:
[snip]
Contents, chapter 2.1:
I think a general "motivation" behind the REASONS to WHY the world
evolved into OOP instead of functional programming is lacking.


All in good time... ;-)

For this chapter I just stressed how C++ has language features that
directly solve the problems encountered and solved less elegantly and less
safely in earlier chapters.

That's sort of personal motivation to start using classes; why the
world at large did so is, summary, (0) Vannevar Bush, I hope he's not
a relation to GW, and his technological insights, (1) simulations, Simula,
Norsk Regnesentral / Oslo University late 1960's, -> (2) Alan Kay, trying
to make sense of an Algol compiler that was actually Simula, and also
having picked up the ideas of Bush, -> (3) the Smalltalk GUI + language + OS +
computer + network + usability + pedagogical ideas project at Xerox Palo Alto
Research Center (Xerox PARC) in the middle 1970's to early 1980's, -> (4)
Bjarne Stroustrup doing simulations and as just about everyone else extending
C with OO ideas, cirka 1980, (5) the Apple Lisa, the fruits of Apple being
invited to evaluate Smalltalk, and not being as silly as HP or was it
Tektronix (who tried to make a GUI based on a vector graphics terminal), (6)
the Apple Macintosh, a kind of Lisa Light, (7) X11 and MS Windows, middle to
late 1980's, and I have to ask, whatever became of Taxi and all the other GUIs
for PC's, and not to forget, Niklaus Wirth's Oberon machine Lilith?
[snip]
Btw, I'm still waiting for an answer regarding if I can mirror your
tutorials on the SmartWin website...


I wasn't aware you'd asked. But by all means. _If_ you put a date on it
(when copied), a reference to the original, and wording to the effect that
the copy may not be the latest update. It is of course simpler to just
provide links. That way the site may even be listed in Google! :-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #3
Thomas Hansen wrote:
Alf P. Steinbach wrote:
[snip]
Contents, chapter 2.1:

I think a general "motivation" behind the REASONS to WHY the world
evolved into OOP instead of functional programming is lacking.
A big point in the whole OO motivation the way I see it (some people
will say it's a motivation behind only C++, I'd say OO) is typesafety!
(That's why C++ is THE best OO language even though lacking several big
OO features...)


I might be mis-interpreting your comments here, but type safety little
to do with OO - its only relevant in UP Languages that are static typed.
Dynamic typed languages exist and are also OOPLs.

snipped remaining...
Andrew

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #4
In article <d2**********@news.freedom2surf.net>,
Andrew McDonagh <ne**@andrewcdonagh.f2s.com> wrote:
Thomas Hansen wrote:
Alf P. Steinbach wrote:
[snip]
Contents, chapter 2.1:

I think a general "motivation" behind the REASONS to WHY the world
evolved into OOP instead of functional programming is lacking.
A big point in the whole OO motivation the way I see it (some people
will say it's a motivation behind only C++, I'd say OO) is typesafety!
(That's why C++ is THE best OO language even though lacking several big
OO features...)


I might be mis-interpreting your comments here, but type safety little
to do with OO - its only relevant in UP Languages that are static typed.
Dynamic typed languages exist and are also OOPLs.


And there are many strongly-typed functional programming languages.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #5

Chris Riesbeck wrote:
In article <d2**********@news.freedom2surf.net>,
Andrew McDonagh <ne**@andrewcdonagh.f2s.com> wrote:
Thomas Hansen wrote:
Alf P. Steinbach wrote:
[snip]

>Contents, chapter 2.1:
I think a general "motivation" behind the REASONS to WHY the world evolved into OOP instead of functional programming is lacking.
A big point in the whole OO motivation the way I see it (some people will say it's a motivation behind only C++, I'd say OO) is typesafety! (That's why C++ is THE best OO language even though lacking several big OO features...)
I might be mis-interpreting your comments here, but type safety little to do with OO - its only relevant in UP Languages that are static typed. Dynamic typed languages exist and are also OOPLs.


You're right off course, but both OO and strongly typing both try to
achieve the same goal.
They both want to make sure you don't try to fly with your submarine
and go under water with your plain...
OO by coupling the functions with the type and typesafety by making
sure you have the right type for the right task.
So to differentiate them in the conceptual idea is for most languages
wrong.
Most (good) languages that supports one also supports the other as long
as it can.
Off course after OO and typesafety came around in practical use lots of
other "features" where added (discovered) like reuse, data hiding,
encapsulation, cohesion and so on.
But in the beginning it was all about denying a submarine to fly!

And there are many strongly-typed functional programming languages.


But their motivation is still the same, OO is just after all an
extremity of typesafety.
Instead of having a method signature with a given type and issuing a
compiler warning/error when trying to call the method with the wrong
type you couple the method within the type making it impossible to make
your sub fly...
In practise you're right, in theory I must declare that I dissagree.

But I guess this is one of those subjects where we all do alot of
armwaving and "you know what I mean" stuff...
At least in the theoretical perspective.
Let the chicken and egg problem pass us unnoticed!
;)
Thomas Hansen
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #6
Thomas Hansen wrote:
Chris Riesbeck wrote:
And there are many strongly-typed functional programming languages.

Most (all?) useful high level languages are strongly typed. The last
time I used a weakly typed high level language was programming in TCL,
which was difficult due to its weak typing. The languages I use now (C,
Python, Lisp) are all strongly typed.
But their motivation is still the same, OO is just after all an
extremity of typesafety.
Instead of having a method signature with a given type and issuing a
compiler warning/error when trying to call the method with the wrong
type you couple the method within the type making it impossible to make
your sub fly...
In practise you're right, in theory I must declare that I dissagree.

But I guess this is one of those subjects where we all do alot of
armwaving and "you know what I mean" stuff...
At least in the theoretical perspective.
Let the chicken and egg problem pass us unnoticed!
;)


It seems to me like you're looking at OO backwards. OO to me is about
polymorphism, where you think of things in terms of shared interfaces
and per-call implementations. What is dispatched on doesn't matter as
much to me as that the dispatch exists. The dispatch has the side
effect of type-safety, but that has never seemed to me to be the prime
motivation.

-- MJF

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #7
Thomas Hansen wrote:
Chris Riesbeck wrote:
Andrew McDonagh wrote:
I might be mis-interpreting your comments here, but type safety
little to do with OO - its only relevant in UP Languages that are
static typed.

Dynamic typed languages exist and are also OOPLs.
You're right off course, but both OO and strongly typing both try to
achieve the same goal.
They both want to make sure you don't try to fly with your submarine
and go under water with your plain...
OO by coupling the functions with the type and typesafety by making
sure you have the right type for the right task.
So to differentiate them in the conceptual idea is for most languages
wrong.
OOP emphasizes the following concepts:
Objects;
Abstraction;
Encapsulation;
Polymorphism; and
Inheritance.

Whether or not datatyping is done at compilation or runtime is
orthogonal to the above concepts [1].
And there are many strongly-typed functional programming languages.


But their motivation is still the same, OO is just after all an
extremity of typesafety.


Type safety merely mandates that the type of data objects is fixed and
does not vary over the lifetime of the object. This has nothing to do
with the concepts emphasized by OOP.
Instead of having a method signature with a given type and issuing a
compiler warning/error when trying to call the method with the wrong
type you couple the method within the type making it impossible to make
your sub fly...
In practise you're right, in theory I must declare that I dissagree.


Don't give your submarine a fly() method (unless you want it too, of
course) :P .

Or, if you mean a fly() method on a pilot, there are two equally valid
approaches:
1. Give it the ability to fly various classes: planes, blimps,
helicopters, dragons, etc.; or
2. Give it the ability to fly anything with yaw, pitch and roll controls.

Static typing is the first approach, dynamic typing is the second.
[1] With the exception of polymorphism. It can be argued that dynamic
typing automatically implies/enables (parametric) polymorphism without
needing any special language constructs.

TTFN,
--
Ben M.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #8
* Ben Measures:

Type safety merely mandates that the type of data objects is fixed and
does not vary over the lifetime of the object. This has nothing to do
with the concepts emphasized by OOP.


Type safety does not mandate that the type of data objects is fixed.

Smalltalk is a language that provides for type safety mainly via dynamic type
checking (I don't know whether there is static checking in modern Smalltalks).

C++ is a language that provides for type safety in some cases via dynamic type
checking.

I think it can be argued that Smalltalk is effectively more type safe than C++
(I also think the opposite can be argued, and then it boils down to what kinds
of type safety one cares about the most in any particular context).

However, I'm not sure that it's Good to single out type safety as what OO is
all about, and say that that is mainly what this tool is for. Rather, I think
a certain ease of providing type safety is a _requirement_ for any successful
OO mechanism, because it's difficult or meaningless to apply abstraction when
any object can be anything, or invalid wrt. the assumed type. C++ is
interesting in this respect because the C++ mechanisms for ensuring type
safety are very pragmatic ones where the difficulties mount exponentially the
stronger your goal of type safety is, and yet it has, in practice, been good
enough that C++ is a very successful language, used for very complex systems.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #9

M Jared Finder wrote:
[snip]
But their motivation is still the same, OO is just after all an
extremity of typesafety.
Instead of having a method signature with a given type and issuing a compiler warning/error when trying to call the method with the wrong type you couple the method within the type making it impossible to make your sub fly...
In practise you're right, in theory I must declare that I dissagree.
But I guess this is one of those subjects where we all do alot of
armwaving and "you know what I mean" stuff...
At least in the theoretical perspective.
Let the chicken and egg problem pass us unnoticed!
;)
It seems to me like you're looking at OO backwards. OO to me is

about polymorphism, where you think of things in terms of shared interfaces and per-call implementations. What is dispatched on doesn't matter as much to me as that the dispatch exists. The dispatch has the side
effect of type-safety, but that has never seemed to me to be the prime motivation.


Might be OO is polymorphism for you, but the single most importent
feature today with OO according to it's "creators" is Data Hiding also
known as Encapsulation!
You've got a "black box" you know if you feed it a direction it will
try to move in that direction, how this is being done is up to the
implementation to decide.
If this is a shared interface, a template policy, a concrete class is
less importent.
The point is that it may rely upon 500 non visible functions and 1000
private data-members which you don't even know exists!
Before OO we had stuff like (C) void * (typesafety), struct's where all
the data was "wide open" to manipulate for everyone (no encapsulation)
etc.
Basically if you had a bug somewhere you had a scope of "all the code".
After OO we could narrow that scope to only public functions and public
data in the class.
OO is about RESTRICTING developers from doing things (data hiding,
encapsulation, typesafety), not ENABLING them to do things
(polymorphism, inheritence etc.)

Ask your self how many times you've used virtual functions and how many
times you've used private data-members/function-members...
;)

[2_cents_of_zen_philosophy_in_the_morning]

The perfect class has no public members, no public data, can not be
copied, can not be assigned to, can not be instantiated and can not be
destroyed...
That's the perfect class!
(ref: If something is available it will cause trouble! )

[/2_cents_of_zen_philosophy_in_the_morning]

Thomas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #10

Ben Measures wrote:
[snip]
And there are many strongly-typed functional programming languages.
But their motivation is still the same, OO is just after all an
extremity of typesafety.


Type safety merely mandates that the type of data objects is fixed

and does not vary over the lifetime of the object. This has nothing to do with the concepts emphasized by OOP.
Instead of having a method signature with a given type and issuing a compiler warning/error when trying to call the method with the wrong type you couple the method within the type making it impossible to make your sub fly...
In practise you're right, in theory I must declare that I
dissagree.
Don't give your submarine a fly() method (unless you want it too, of
course) :P .


The difference between a typesafe language and a non typesafe language
is that a typesafe language has some kind of built in logic to
guarantee that you don't try to submit a "submarine" parameter to a
function which takes an "aeroplane" object...
Not totally unlike the princips of binding the "can do" (functions)
with the type (data) as in classes.
If this happens compile time you have a guarantee that it will NEVER
happen, if this happens runtime (dynamically typed languages) you'd
better hope your function is being called with the "wrong parameter" in
your Unit Tests!

Example:
var x = 5
var y = "5"
var z = x+y

What's the z variable containing here?
At least four possible candidates exists.
10, 55, "55" and "error"...

[snip]
Thomas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #11
Thomas Hansen wrote:
Chris Riesbeck wrote:
In article <d2**********@news.freedom2surf.net>,
Andrew McDonagh <ne**@andrewcdonagh.f2s.com> wrote:
Thomas Hansen wrote:
> Alf P. Steinbach wrote:
> [snip] >>Contents, chapter 2.1: > I think a general "motivation" behind the REASONS to WHY
> the world evolved into OOP instead of functional
> programming is lacking. A big point in the whole OO
> motivation the way I see it (some people will say it's a
> motivation behind only C++, I'd say OO) is typesafety!
> (That's why C++ is THE best OO language even though
> lacking several big OO features...) I might be mis-interpreting your comments here, but type
safety little to do with OO - its only relevant in UP
Languages that are static typed. Dynamic typed languages
exist and are also OOPLs.
You're right off course, but both OO and strongly typing both
try to achieve the same goal. They both want to make sure you
don't try to fly with your submarine and go under water with
your plain...
I'm not sure. In some ways, the goal of OO is to allow the
submarine to do whatever it has to to fly:-). (Presumably, what
it has to do is different than what a plane has to do.)

The problem with the word OO is that it has become an in thing,
so people apply it to everything. I'm not sure what it really
means any more. And while I think that there is a sense in
which you are formally right concerning type safety, I suspect
that this isn't true for the most common uses of type safety and
OO.
OO by coupling the functions with the type and typesafety by
making sure you have the right type for the right task.
If I understood Booch correctly, OO implies dynamic
polymorphism. If you don't have virtual functions, it isn't
OO. The type safety aspect is secondary.
So to differentiate them in the conceptual idea is for most
languages wrong. Most (good) languages that supports one also
supports the other as long as it can. Off course after OO and
typesafety came around in practical use lots of other
"features" where added (discovered) like reuse, data hiding,
encapsulation, cohesion and so on. But in the beginning it
was all about denying a submarine to fly! From what I understand about Smalltalk (the language for which the word "object oriented" was invented), it was more a case of
empowering a submarine to fly, if it wanted to.
And there are many strongly-typed functional programming
languages.

But their motivation is still the same, OO is just after all
an extremity of typesafety. Instead of having a method signature with a given type and
issuing a compiler warning/error when trying to call the
method with the wrong type you couple the method within the
type making it impossible to make your sub fly...


That's a particularity of C++/Eiffel/Java/Ada95. It certainly
wasn't the case in Smalltalk.

When I think of strong static typing, or type safety, I think of
the Pascal family of languages. (Pascal arguably took strong
typing too far -- the length of an array was part of the type,
and you couldn't write a procedure which took an array of a
dynamically specified length.) I'd say that the OO part of C++
is involved in loosening the type system -- in a controlled
manner, because C++ remains statically typed. Never the less,
it allows me to pass objects of different types to the same
function, which is the opposite of strong static type safety.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #12

ka***@gabi-soft.fr wrote:
[snip]
You're right off course, but both OO and strongly typing both
try to achieve the same goal. They both want to make sure you
don't try to fly with your submarine and go under water with
your plain...
I'm not sure. In some ways, the goal of OO is to allow the
submarine to do whatever it has to to fly:-). (Presumably, what
it has to do is different than what a plane has to do.)


;)
Well, I was trying to illustrate what could be a disastreous thing in a
weakly typed language lacking capabilities for coupling the type (data)
with the "can do" (functions)...
I assume you understand me, but for the clearity of other readers (this
post is going to several groups) I'll explain...

The above scenario of asubmarine trying to fly is a normal metaphor for
when things have gone REALLY bad!
These types of bugs where quite common to experience in earlier days
when you where sending void pointers around everywhere!
Also this is a problem many newbies experience even in more "secure"
languages like C++ etc, but they are more "difficult" to experience in
"better" languages...
You can imagine Churchill standing on Normandie in 1945 with something
he thought was supposed to be bombers but instead was submarines and
just when he tries to fly them he understands the mistake he has
done...
That's the type of problems you can drown in in a weakly typed language
lacking "OO" capabilities...

And that's where the "denial" comes into the picture, they both are
trying to "deny" you to fly a submarine...
Both OO and typesafety is all about denying!
Typesafety makes sure you don't supply a Submarine object to a fly
function and OO makes sure the Submarine class doesn't contain the fly
function.

The problem with the word OO is that it has become an in thing,
so people apply it to everything. I'm not sure what it really
means any more.
I can partially agree here, it's a "hyped" word...
In the late 90's they were almost selling fridges which was Object
Oriented!
(I wonder how you could inherit from the milk bottle and override the
Dispose function... ;)
And while I think that there is a sense in
which you are formally right concerning type safety, I suspect
that this isn't true for the most common uses of type safety and
OO.
No I am not formally right whatsoever!
You are!
But to separate two different mechanisms which occured around the same
time in evolution both trying to solve the same problems in the same
domain would be like separating brown eyes from blue!
Sure it can be done, but what's the point?
Those with brown eyes are neither dumber nor more intelligent then
those with blue eyes...
And they both percieve the world in roughly the same way.

(when that's said they off course have tons of qualities which the
other does not have but their one main biggest feature (denial) is
common for both)

If you see the evolution of C++ you will see that Bjarne implemented
features according to a priority list (at least he says so himself),
and the strongly typing system was one of the FIRST features he did,
long before e.g. exceptions and templates...
OO by coupling the functions with the type and typesafety by
making sure you have the right type for the right task.
If I understood Booch correctly, OO implies dynamic
polymorphism. If you don't have virtual functions, it isn't
OO.


True!
The type safety aspect is secondary.
True!
I don't even think the typesafety is mentioned in the OO
"definition"...
So to differentiate them in the conceptual idea is for most
languages wrong. Most (good) languages that supports one also
supports the other as long as it can. Off course after OO and
typesafety came around in practical use lots of other
"features" where added (discovered) like reuse, data hiding,
encapsulation, cohesion and so on. But in the beginning it
was all about denying a submarine to fly!
From what I understand about Smalltalk (the language for which

the word "object oriented" was invented), it was more a case of
empowering a submarine to fly, if it wanted to.
And there are many strongly-typed functional programming
languages.

But their motivation is still the same, OO is just after all
an extremity of typesafety.

Instead of having a method signature with a given type and
issuing a compiler warning/error when trying to call the
method with the wrong type you couple the method within the
type making it impossible to make your sub fly...


That's a particularity of C++/Eiffel/Java/Ada95.


C#/Simula/Python/etc...
It certainly
wasn't the case in Smalltalk.
I know nothing about Smalltalk unfortunately...
But It sounds interesting if they managed to create something definable
as OO today without coupling functions within the types...

When I think of strong static typing, or type safety, I think of
the Pascal family of languages. (Pascal arguably took strong
typing too far -- the length of an array was part of the type,
and you couldn't write a procedure which took an array of a
dynamically specified length.) I'd say that the OO part of C++
is involved in loosening the type system
That might be true, but Bjarne had to take C compatibility into
account...
I think C++ wouldn't look like it did if it wasn't for C...
-- in a controlled
manner, because C++ remains statically typed. Never the less,
it allows me to pass objects of different types to the same
function, which is the opposite of strong static type safety.


( ...C compatibility yet again... )
Thomas Hansen
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #13
Thomas Hansen wrote:
M Jared Finder wrote:

<snip>
It seems to me like you're looking at OO backwards. OO to me is
about polymorphism, where you think of things in terms of shared
interfaces and per-call implementations. What is dispatched on
doesn't matter as much to me as that the dispatch exists. The
dispatch has the side effect of type-safety, but that has never
seemed to me to be the prime motivation.


Might be OO is polymorphism for you, but the single most importent
feature today with OO according to it's "creators" is Data Hiding also
known as Encapsulation!

<snip>

Abstract data types (ADT) also provide encapsulation, whereas not
every version of OOP does. For example in Python privacy of object
attributes is merely a convention. Polymorphism is the really
essential feature of OOP.

Ben.

--
Ben Hutchings
Having problems with C++ templates? Your questions may be answered by
<http://womble.decadentplace.org.uk/c++/template-faq.html>.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #14
Thomas Hansen wrote:
M Jared Finder wrote:
[snip]
But their motivation is still the same, OO is just after all an
extremity of typesafety.
Instead of having a method signature with a given type and issuing
a
compiler warning/error when trying to call the method with the
wrong
type you couple the method within the type making it impossible to
make
your sub fly...
In practise you're right, in theory I must declare that I
dissagree.
But I guess this is one of those subjects where we all do alot of
armwaving and "you know what I mean" stuff...
At least in the theoretical perspective.
Let the chicken and egg problem pass us unnoticed!
;)
It seems to me like you're looking at OO backwards. OO to me is


about
polymorphism, where you think of things in terms of shared interfaces


and per-call implementations. What is dispatched on doesn't matter


as
much to me as that the dispatch exists. The dispatch has the side
effect of type-safety, but that has never seemed to me to be the


prime
motivation.

Might be OO is polymorphism for you, but the single most importent
feature today with OO according to it's "creators" is Data Hiding also
known as Encapsulation!
You've got a "black box" you know if you feed it a direction it will
try to move in that direction, how this is being done is up to the
implementation to decide.
If this is a shared interface, a template policy, a concrete class is
less importent.


I'm not sure how to say this, but what you are describing is
*abstraction*, and not object oriented design. Dictionary.com has the
following definition for abstraction: Ignoring or hiding details to
capture some kind of commonality between different instances.

Abstraction is a very good thing (and I'd say it is the fundamental
skill of thinking), but it is no more tied to OO than structured
programming or functional programming.

You deal with many non-OO abstractions every day -- function calls are
an abstraction of control flow, local variables are an abstraction of
memory allocation, assembly language is an abstraction of the
organization of a CPU's logic gates' interconnections. As you said, OO
is about abstraction in terms of shared interfaces, which requires
dynamic dispatch.
The point is that it may rely upon 500 non visible functions and 1000
private data-members which you don't even know exists!
Before OO we had stuff like (C) void * (typesafety), struct's where all
the data was "wide open" to manipulate for everyone (no encapsulation)
etc.
Basically if you had a bug somewhere you had a scope of "all the code".
After OO we could narrow that scope to only public functions and public
data in the class.
This is completely untrue. If there is a bug in your code, without
tests, you cannot know if the bug is on the client side or in the
implementation.

Again, abstraction helps here, not OO. (Remember, OO is just a type of
abstraction.) As long as your abstractions are kept clean, then you can
quickly isolate what causes a bug by looking at each abstraction
individually and seeing where the assumed behavior is different from the
actual behavior. See pre-conditions, post-conditions, and invariants,
another non-OO concept.
OO is about RESTRICTING developers from doing things (data hiding,
encapsulation, typesafety), not ENABLING them to do things
(polymorphism, inheritence etc.)

Ask your self how many times you've used virtual functions and how many
times you've used private data-members/function-members...
;)
I use abstractions much more than I use dynamic dispatch. But in
regards to your specific example, I rarely use C++-style private data
members and functions. The fact that I do most of my programming in C
and Lisp probably contributes to that. ;)
[2_cents_of_zen_philosophy_in_the_morning]

The perfect class has no public members, no public data, can not be
copied, can not be assigned to, can not be instantiated and can not be
destroyed...
That's the perfect class!
(ref: If something is available it will cause trouble! )

[/2_cents_of_zen_philosophy_in_the_morning]


Assuming the perfect computer would only run perfect programs, which can
only be written using perfect classes, we can deduce that the perfect
program can not do anything since the perfect classes can not do
anything, even exist. From this, it's simple enough to see that the
perfect computer is one that is off, because if it was on, the programs
it is running must be imperfect, since they are doing something.

I'll take my imperfect computer over your perfect computer every day of
the week. My computer is useful.

-- MJF

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #15
Thomas Hansen wrote:
ka***@gabi-soft.fr wrote:
[snip]
Instead of having a method signature with a given type and
issuing a compiler warning/error when trying to call the
method with the wrong type you couple the method within the
type making it impossible to make your sub fly...


That's a particularity of C++/Eiffel/Java/Ada95.

C#/Simula/Python/etc...

It certainly
wasn't the case in Smalltalk.

I know nothing about Smalltalk unfortunately...
But It sounds interesting if they managed to create something definable
as OO today without coupling functions within the types...


I'd be interested in what you thought of the Common Lisp Object System.
I find its take on OO to be the most usable because it separates
dynamic dispatch and method combination from type definition. The cool
thing about this is that some OO design patterns are no longer needed.
The Visitor pattern is completely useless in CLOS specifically because
generic functions are separated from the tyranny of the classes.

-- MJF

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #16
Thomas Hansen wrote:
ka***@gabi-soft.fr wrote:
[snip]
You're right off course, but both OO and strongly typing
both try to achieve the same goal. They both want to make
sure you don't try to fly with your submarine and go under
water with your plain...
I'm not sure. In some ways, the goal of OO is to allow the
submarine to do whatever it has to to fly:-). (Presumably,
what it has to do is different than what a plane has to do.)
;) Well, I was trying to illustrate what could be a disastreous
thing in a weakly typed language lacking capabilities for
coupling the type (data) with the "can do" (functions)...
I assume you understand me, but for the clearity of other
readers (this post is going to several groups) I'll explain...
The above scenario of asubmarine trying to fly is a normal
metaphor for when things have gone REALLY bad!
These types of bugs where quite common to experience in
earlier days when you where sending void pointers around
everywhere!
Also this is a problem many newbies experience even in more
"secure" languages like C++ etc, but they are more "difficult"
to experience in "better" languages...
I certainly don't dispute that the lack of type safety can be a
problem. I'm all in favor of strong typing, preferably static.
But in some ways, typing and encapsulation are orthogonal. In
C, one classical way to encapsulate is to use a void* as a sort
of a universal handle. You have a function createXXX which
returns a void*, and an number of other functions
doSomethingWithXXX which take a void* as their first parameter.
This is highly encapsulated, and probably meets Alan Kay's
original definition of OO (although he might have also insisted
on polymorphism), but it is anything but typesafe.

[...] The problem with the word OO is that it has become an in
thing, so people apply it to everything. I'm not sure what
it really means any more. I can partially agree here, it's a "hyped" word... In the
late 90's they were almost selling fridges which was Object
Oriented! (I wonder how you could inherit from the milk
bottle and override the Dispose function... ;)
There's an interesting annecdote at
http://c2.com/cgi/wiki?HeInventedTheTerm :-).

Of course, exact meanings evolve -- Alan Kay has also been
quoted as saying "I made up the term 'object-oriented', and I
can tell you I didn't have C++ in mind" :-). More to the point,
it seems clear from many things that Kay has said that he
considers full dynamic typing essential to OO; another OO guru,
Bernard Meyers, considers static typing essential to modern OO.
Alan Kay's earliest statements don't seem to consider
polymorphism essential, although most modern pundits (including
Kay, I think) do -- Booch distinguishes object oriented (with
dynamic polymorphism) from object based (all of the
encapsulation, but without polymorphism).
And while I think that there is a sense in which you are
formally right concerning type safety, I suspect that this
isn't true for the most common uses of type safety and OO. No I am not formally right whatsoever!
You are!
But to separate two different mechanisms which occured around
the same time in evolution both trying to solve the same
problems in the same domain would be like separating brown
eyes from blue! Sure it can be done, but what's the point?
Those with brown eyes are neither dumber nor more intelligent
then those with blue eyes... And they both percieve the world
in roughly the same way.
OK. By formally right, I meant simply that whatever concepts
you consider OO do interact in some way with a type system. The
type of an object is determined by the set of possible states
and the operations allowed on it. And OO is certainly concerned
with the set of possible states and operations.

What I see as a minimum in all definitions of OO (or even
Booch's object based) is encapsulation. Hiding the state, and
only exposing a subset (of state and operations -- typically
most of the operations, but little of the state). It's this
encapsulation which makes polymorphism possible. Rather than
requiring an exact type, it allows you to use any type which
supports the desired operations. In that sense, it goes in the
opposite direction of strong typing.

I would argue that strong (static) typing and OO are two
distinct developments, which occured at about the same time
(Pascal and Smalltalk), but which actually went in radically
different directions, at least at the start. Both brought
important advantages, and much of following the development
(including such languages as C++ and Eiffel) have been attempts
to merge these two developments.
(when that's said they of course have tons of qualities which
the other does not have but their one main biggest feature
(denial) is common for both)
Denial is NOT a characteristic of early OO. At least not of
Smalltalk. I would qualify early OO as more enablement. To get
back to your original example: I don't have to know what type an
object is to fly it. All I need is that it has a method "fly".
And that method can be added to any type I want.

Many (most) later "OO" languages take a more restrictive view;
that a class must explicitly declare that it supports a set of
operations, by deriving from a class which declares the
interface. Thus, for example, if the interface contains the
functions "fly", "land" and "takeoff", an object cannot support
flying without also supporting landing and taking off.
If you see the evolution of C++ you will see that Bjarne
implemented features according to a priority list (at least he
says so himself), and the strongly typing system was one of
the FIRST features he did, long before e.g. exceptions and
templates...
Yes, but as far as I can see, it was never a goal of C++ to be
"purely object oriented", or anything else but useful.
Encapsulation is a very useful feature. So is strong static
type checking.

Concerning the priorities of C++, it's also important to see
where it was coming from. C has fairly weak typing, and while
C++ has improved it greatly, there are still weak points, as
anyone who has done something like "aString += aDouble" can
attest to.

[...] Instead of having a method signature with a given type and
issuing a compiler warning/error when trying to call the
method with the wrong type you couple the method within
the type making it impossible to make your sub fly...

That's a particularity of C++/Eiffel/Java/Ada95. C#/Simula/Python/etc...
I'm not familiar with them, so I don't know:-). On the other
hand, Smalltalk and CLOS definitly do not have static typing, at
all.

And of course, different communities use it in different ways.
There are a lot of interfaces in Java which simply deal with
Object, and leave you to guess the actual type, once you get it.
Which results in de facto dynamic type checking instead of
static. And numerous run-time errors instead of the compiler
complaining (but also certain freedoms which you don't have in
C++).
It certainly wasn't the case in Smalltalk. I know nothing about Smalltalk unfortunately...
I don't know it very well myself. But I know some of the
principles behind it.
But It sounds interesting if they managed to create something
definable as OO today without coupling functions within the
types...
It depends on what you mean by "definable". The basic principle
is simple: everything is an Object. Rather than "call
functions", you "send messages". The receiving object looks up
the message type in a table it contains, which maps message type
to method code, and either invokes the method code or
complains. I'm not too sure how it handles parameters, but if
it's anything like Lisp (on which it is based), the parameters
are just a list of Object, and it is up to the invoked method to
verify number and whether a given parameter supports the
needed operations.

I'd hate to try and develop robust software in such an
environment, but apparently, people do so, and do so well.
When I think of strong static typing, or type safety, I
think of the Pascal family of languages. (Pascal arguably
took strong typing too far -- the length of an array was
part of the type, and you couldn't write a procedure which
took an array of a dynamically specified length.) I'd say
that the OO part of C++ is involved in loosening the type
system That might be true, but Bjarne had to take C compatibility
into account...
I think C++ wouldn't look like it did if it wasn't for C...
Certainly not. But I think that Bjarne rather favors (or at
least favored at one time) strong static type checking. At
least, one aspect of the evolution of C++ has been in this
direction.
-- in a controlled manner, because C++ remains statically
typed. Never the less, it allows me to pass objects of
different types to the same function, which is the opposite
of strong static type safety.

( ...C compatibility yet again... )


Not at all. C compatibility certainly didn't require
inheritance and virtual functions. Which is what I was talking
about -- I declare my function to take a Base&, and you can pass
it a Derived1, or a Derived2, or any number of other types.

This is Smalltalk's enablement -- a possibility to take
liberties with the type system. In the case of C++, it's a
constrained enablement; you can't do just anything.

Of course, there is also a (static) polymorphism due to the fact
that a double implicitly converts to int (or even to char).
Which allows things like the "aString += aDouble" above. That
IS due to C compatibility:-). (And I consider it more a bug
than a feature. Part of the price we had to pay for the
language to become widely used.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #17

M Jared Finder wrote:
[snip]
Might be OO is polymorphism for you, but the single most importent
feature today with OO according to it's "creators" is Data Hiding also known as Encapsulation!
You've got a "black box" you know if you feed it a direction it will try to move in that direction, how this is being done is up to the
implementation to decide.
If this is a shared interface, a template policy, a concrete class is less importent.
I'm not sure how to say this, but what you are describing is
*abstraction*, and not object oriented design.


ehh...
And so?
I didn't state I was talking about OOD, I said (self quote) "the single
most importent feature of OO".
And all though abstraction is also possible to get in non-OO languages
it is far more difficult and doesn't come with the language "by
default" in the same extent as in OO languages.
Now if you bring in abstraction to the level where you can say that OP
code in binary form is an abstraction of electricity in a circuit and
thereby can declare that Assembler code have several abstraction layers
underneath it before hitting the iron I guess you can say all languages
have abstractions and be formally right...

Now relity check ( ;) ):
Where you can in C e.g. declare your "private" data directly in the
definition file you can declare them in your declaration file in C++
but still have them "hidden" from "outsiders".
And while you can in C choose not to declare your functions in any
declaration files and still use them as "private functions" you can in
C++ declare them in a declaration file and still be able to "hide"
them, you can even inherit from another class and only expose your
object as being of this other base type and thereby "hide" the fact
that this current object is not a "dog" but rather a "mammal" or
something.
To do the last in C requires bug prune code with lots of magic switches
and control flow statements...
(mark, the list of abstraction possibilities in C was not ment to be
exhaustive)

Those are FEATURES of C++. (and other OO languages)
But you are totally right it's called abstractions, that fact however
doesn't in any way contradict with the fact that they are still no
matter how you look at it the most importent features of OOP, OOD and
probably also OOX. (what ever that may be ;)

[snip]
Abstraction is a very good thing (and I'd say it is the fundamental
skill of thinking),
Depends on how many associations you can do before loosing control of
your mind...
;)
but it is no more tied to OO than structured
programming or functional programming.
Abstraction is in no way tied to OO, but OO is in all ways tied to
abstraction.
I guess you can say that the biggest generalized class OO inherits from
is abstraction, now that doesn't make abstraction a subclass of OO
though...

You deal with many non-OO abstractions every day -- function calls are an abstraction of control flow, local variables are an abstraction of
memory allocation, assembly language is an abstraction of the
organization of a CPU's logic gates' interconnections. As you said, OO is about abstraction in terms of shared interfaces, which requires
dynamic dispatch.
Yup, still OO's abstraction mechanisms are a 100 times better then NON
OO languages abstraction mechanisms... (at least the NON OO languages I
am familiar with)
The point is that it may rely upon 500 non visible functions and 1000 private data-members which you don't even know exists!
Before OO we had stuff like (C) void * (typesafety), struct's where all the data was "wide open" to manipulate for everyone (no encapsulation) etc.
Basically if you had a bug somewhere you had a scope of "all the code". After OO we could narrow that scope to only public functions and public data in the class.
This is completely untrue. If there is a bug in your code, without
tests, you cannot know if the bug is on the client side or in the
implementation.


If there is a bug in your code you can rest assured that it has at some
point emerged into your code through it's "abstraction parts" or it is
inside your code, meaning that no other code then the code having the
right to do so could possibly have changed the value of variable x, now
if variable x is a global variable "all the code" could have introduced
the value of variable x, if the variable x is a private data member of
a class only the class could itself have changed that value to the
garbage value!
(Suggested reading: Exceptional C++, especially the parts about
encapsulation)

Again, abstraction helps here, not OO.
Here you are right, OO languages have though still better abstraction
capabilities and mechanisms then NON OO languages... (yet again those I
have seen)
(Remember, OO is just a type of
abstraction.) As long as your abstractions are kept clean, then you can quickly isolate what causes a bug by looking at each abstraction
individually and seeing where the assumed behavior is different from the actual behavior. See pre-conditions, post-conditions, and invariants, another non-OO concept.
Design by contract and asserts are powerful, and you can quickly
eliminate large portions of your code in debugging while looking for
bugs with them, however they don't help you in getting a clean
interface to your code or a good abstraction layer to client code
utilizing your code.
OO is about RESTRICTING developers from doing things (data hiding,
encapsulation, typesafety), not ENABLING them to do things
(polymorphism, inheritence etc.)

Ask your self how many times you've used virtual functions and how many times you've used private data-members/function-members...
;)
I use abstractions much more than I use dynamic dispatch. But in
regards to your specific example, I rarely use C++-style private data
members and functions. The fact that I do most of my programming in

C and Lisp probably contributes to that. ;)
Well OO languages has built in mechanisms to make it easy to make very
powerful and clean abstractions compared to other NON OO languages.
Does that make C++ better then C?
For most of my purposes the answer is YES!
But I realize other people have other needs and in other scenarios.
[2_cents_of_zen_philosophy_in_the_morning/]

Assuming the perfect computer would only run perfect programs, which

can only be written using perfect classes, we can deduce that the perfect
program can not do anything since the perfect classes can not do
anything, even exist. From this, it's simple enough to see that the
perfect computer is one that is off, because if it was on, the programs it is running must be imperfect, since they are doing something.

I'll take my imperfect computer over your perfect computer every day of the week. My computer is useful.


Well Zen philosophy often is like that, impossible to follow and of
more poetic value then concrete value...

Still the lessons learned are valuable, deny your code to do things by
default and open up on a demand basis.
Imagine how many bugs would have been gone if C++ didn't define default
CTOR's and CopyCTORs for classes...
Thomas Hansen
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #18

Ben Hutchings wrote:
[snip]

Might be OO is polymorphism for you, but the single most importent
feature today with OO according to it's "creators" is Data Hiding also known as Encapsulation!

<snip>

Abstract data types (ADT) also provide encapsulation, whereas not
every version of OOP does. For example in Python privacy of object
attributes is merely a convention. Polymorphism is the really
essential feature of OOP.


I guess you can argue for polymorphism being a part of encapsulation
since it hides away the details of the implementation.
At least that's the idea of polymorphism the way I see it.
You've got a mammal object with a public function "move" in the Bird
class which maps to "Fly" while in the Dog class this maps to "Walk".
So to state that polymorphism "hides" the internals of the function
wouldn't be directly wrong.
Probably a bad association by me to use the words Data Hiding!

Still I think that encpsulation (or "abstraction") is the single
largest and most importent feature of OO.
In just the same mattter that "type abstraction" is the single most
importent feature of generic classes. (templates)
Might be a definition of templates can't call itself confining unless
it's got this or that ( ref: export ;) still you wouldn't define the
biggest feature of templates to be it's ability to export
implementation into a definition file...?
In just the same manner I'd not define OO's best asset to be it's
ability to call overridden functions.
I'd like to define it as it's ability to abstract away the
implementation leaving only the "interface" (or public functions) left
for the client code to use...

Thomas Hansen
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #19
Thomas Hansen wrote:
M Jared Finder wrote:
[snip]
Might be OO is polymorphism for you, but the single most importent
feature today with OO according to it's "creators" is Data Hiding also
known as Encapsulation!
You've got a "black box" you know if you feed it a direction it will
try to move in that direction, how this is being done is up to the
implementation to decide.
If this is a shared interface, a template policy, a concrete class is
less importent.


I'm not sure how to say this, but what you are describing is
*abstraction*, and not object oriented design.

ehh...
And so?
I didn't state I was talking about OOD, I said (self quote) "the single
most importent feature of OO".
And all though abstraction is also possible to get in non-OO languages
it is far more difficult and doesn't come with the language "by
default" in the same extent as in OO languages.
Now if you bring in abstraction to the level where you can say that OP
code in binary form is an abstraction of electricity in a circuit and
thereby can declare that Assembler code have several abstraction layers
underneath it before hitting the iron I guess you can say all languages
have abstractions and be formally right... Now relity check ( ;) ):
Where you can in C e.g. declare your "private" data directly in the
definition file you can declare them in your declaration file in C++
but still have them "hidden" from "outsiders".


Many OO languages do not have the concept of private member
variables/functions. Every member is public, and it is only by
convention that certain members are off limits. Python, Smalltalk and
Lisp all come to mind as OO languages without the private qualifier.

Or do you consider Smalltalk, the language that made OO popular, not an
object oriented language precisely because it does not have the concept
of private members?

-- MJF

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #20

M Jared Finder wrote:
[snip]
Or do you consider Smalltalk, the language that made OO popular, not an object oriented language precisely because it does not have the concept of private members?


No, but (a little bit boored in repeating myself) I consider it's
ability to hide internal implementation OO's biggest feature...

..t
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #21
Thomas Hansen wrote:
M Jared Finder wrote:
[snip]
Or do you consider Smalltalk, the language that made OO popular, not an
object oriented language precisely because it does not have the concept
of private members?


No, but (a little bit boored in repeating myself) I consider it's
ability to hide internal implementation OO's biggest feature...


But not all OO languages have this "feature"! Smalltalk, Python, and
Common Lisp all have no concept of private members built in to the
language; if you want to have a private member it must be enforced by
convention (or with Lisp, by macros enforcing the convention).

Since these languase are considered OO by many other people, there are
only three possible conclusions:

1. Your definition of OO is different from everybody else's definition
of OO.

2. Smalltalk, Python, and Common Lisp are not OO languages.

3. OO is orthogonal to private members.

I choose 3, because I do not see any benefit to making OO include
private members, striking down 1, and I find 2 to be just silly, since
that would exclude Smalltalk from being an OO language. Which one do
you choose?

-- MJF

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #22

M Jared Finder wrote:
[snip]
No, but (a little bit boored in repeating myself) I consider it's
ability to hide internal implementation OO's biggest feature...
But not all OO languages have this "feature"! Smalltalk, Python, and
Common Lisp all have no concept of private members built in to the
language; if you want to have a private member it must be enforced by
convention (or with Lisp, by macros enforcing the convention).


Excuse me for asking but have you read what I have been writing at all?

Since these languase are considered OO by many other people, there are only three possible conclusions:
Well according to the "mainstream" definition of OOP among other things
the language needs to support polymorphism (also according to our good
Smalltalk friend Alan)
Polymorphism is one way to hide implementation details from use of
object.
The language also needs to support inheritance which is also another
way to hide implementation.

1. Your definition of OO is different from everybody else's definition of OO.
I have never talked about the definition of OO, I have been talking
about (all the time) OOP's main feature, which still is it's ability to
hide implementation details.

2. Smalltalk, Python, and Common Lisp are not OO languages.
Well if they don't support polymorphism or inheritance they aren't!
(my guess is that they do support the mentioned mechanisms though)

3. OO is orthogonal to private members.


I have never stated that OO is in anyway dependant on the language
ability to do private data/function members...
If you feel I have then please let me know where and I'll try to clear
up the misunderstandings...

Thomas Hansen
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #23
In article <Gq********************@speakeasy.net>,
M Jared Finder <ja***@hpalace.com> wrote:
Thomas Hansen wrote:
M Jared Finder wrote:
Since these languase are considered OO by many other people, there are
only three possible conclusions:<snip>3. OO is orthogonal to private members.


I have never stated that OO is in anyway dependant on the language
ability to do private data/function members...
If you feel I have then please let me know where and I'll try to clear
up the misunderstandings...


I got that impression from your second post to this thread:
Might be OO is polymorphism for you, but the single most importent
feature today with OO according to it's "creators" is Data Hiding also
known as Encapsulation!
You've got a "black box" you know if you feed it a direction it will
try to move in that direction, how this is being done is up to the
implementation to decide.
If this is a shared interface, a template policy, a concrete class is
less importent.
The point is that it may rely upon 500 non visible functions and 1000
private data-members which you don't even know exists!
Before OO we had stuff like (C) void * (typesafety), struct's where all
the data was "wide open" to manipulate for everyone (no encapsulation)
etc.


The reason I replied to this was that you stated that the most important
programming concept -- abstraction -- was invented by OO. This thought
would prevent you from ever becoming a great programmer. A great
programmer realizes that the C++ programming language is just another
abstraction, understands how he could implement that language in a lower
level language, and understands under what conditions he would want that
type of abstraction. I don't see how you could come to that type of
realization if you thought that abstractions only existed as private
data members of a structure.


Since my newsreader triggered on Hansen's name...

At work I do a lot of programming in Igor Pro, which is a data analysis
environment. It has a lot of nice programming features for data
manipulation, displaying data, building GUIs, and so on, but very little
in the way of objects, data hiding, and other things you'd expect from a
modern programming language. I fake classes and encapsulation with data
folders and naming conventions.

--
"And don't skimp on the mayonnaise!"

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #24

M Jared Finder wrote:
[snip]
The reason I replied to this was that you stated that the most important programming concept -- abstraction -- was invented by OO.


Exactly where did I state this?
Thomas Hansen
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #25

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
by: Average_Joe | last post by:
Hello PHP people, Was wondering if PHP5 had some sort of "nested class" functionality. I'm trying to figure out how to return an object (with a private constructor) that has access to...
3
by: TheLetti | last post by:
Hy! I've just downloaded the latest Java 2 SDK (j2sdk1.4.2_01). For my surprise in this version the servlet-classes are not integrated (e.g. the class javax.servlet). So I found all the...
1
by: francois | last post by:
I'm looking for C++ classes library to be used instead of STL. As I'm working on a tiny embedded system 16MB up to 32MB, I need to reduce memory footprint needed by the STL due to its genericity....
9
by: Gomaw Beoyr | last post by:
Two question about the "partial classes" (in the next wersion of ..NET). Question 1 ========== Will partial classes (in the next version of C#) have to be declared "partial" in ALL places. ...
3
by: Giggle Girl | last post by:
I have inherited some CSS from a former employee that has code like this: onmouseover="this.className='highlight_on standard_border'" where it appears to activate two different classes,...
2
by: Ranginald | last post by:
Hi, I have two pages. Default.aspx ....Codefile="default.aspx.cs" Inherits="Web" %> and Sculpture.aspx
4
by: Peter K | last post by:
Hi if I am developing a "class library" which contains some classes which should be exposed to the outside world, and other classes which I really would rather have "private" to my library...
4
by: Christian Joergensen | last post by:
Hello I stumpled upon this "feature" during my work tonight, and found it a bit confusing: .... class C: .... foobar = 42 .... .... <class __main__.C at 0xb7cf735c>
0
by: Clive Dixon | last post by:
When working with lots of associated "supporting" classes alongside classes (by this, I mean things such as associated component editor classes specified by , debugger proxy classes specified by ...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.