why do some writers declare and define variables separately

[Öö Tiib]

It fits when there is a useful concept of lifetime, but, to take one
example, Smalltalk has garbage collection, and there is no concept of
the lifetime of an object that is of any use to the programmer.

That is _the_ problem that destructors solve. Objects have birth and death.
Name one real life object that does not have it? If destructors are missing
then developer can still manually turn object into some custom-made "dead"
state ready for disposal by garbage collector. That is inconvenient if user
does not want to deal with aspect of killing object ("what means i have to
close the configuration?") and also the encapsulation now leaks
information ("you must close the configuration because there is underlying
file open").

In another post (it's a shame I can't reply to both at once) you mention
the huge benefit of destructors in resource management (open file,
dynamically allocated memory and so on).

Benefit is not automatic management of precious resources. OOP does not
need it. OOP involves restricting unneeded access to underlying precious
resources of abstraction and bundling those with needed (for user) operations
that involve the resources. That is called "encapsulation". It can not be done
perfectly if outside user of abstraction _must_ deal with lifetime (to kill,
close, free, join) underlying precious resources of abstraction. Such
manipulations _can_ still be among operations with abstraction but usage
of those _is not_ among mandatory responsibilities of user of abstraction
anymore thanks to destructors.

Where the language has the
right concepts, this is true, but it does not imply an object-oriented
language. One can image C+exceptions in which a variable can be tagged
with code to be executed at the end of its lifetime:

FILE *fp = NULL on byebye = { if (fp) fclose(fp); }

I did nowhere say that destructors (or RAII) can be /only/ used for OOP. Use how
you want. I said that destructor and RAII idiom are very beneficial featurefor
OOP features like information hiding, encapsulation and separation of concerns.

We'd have destructors, but not OO. In other words, the two concepts are
orthogonal. Destructors may not even make sense in an object-oriented
language, and they may be present in one that is not OO.

Yes. Similarly a pine may be in garden, in park or in forest. Pine is not forest,
pine is tree and there may be forest without pine. However there can't be forest
without trees and pine is good, straight tree in forest.

Obviously C++ relates the two by being object-oriented (in part) and by
having destructors, but that does not mean there is any logical
connection between the two concepts.

It is like to claim that there are no logical connections between pine and
forest? World largest forests (see "taiga") are mostly pines, spruces and larches.
So world forests would be _lot_ poorer without those pines.

 

[Ben Bacarisse]

That is _the_ problem that destructors solve. Objects have birth and death.
Name one real life object that does not have it?

The number 42. In Smalltalk, numbers are objects and respond to message
like any other. I think you have decided that objects must correspond
to things in "real life" (is a number such a thing? I don't know) and
that they must have a "death" that the programmer in charge of. You
may, in other words, be defining the term so that a destructor plays a
central role.

Benefit is not automatic management of precious resources. OOP does not
need it. OOP involves restricting unneeded access to underlying precious
resources of abstraction and bundling those with needed (for user) operations
that involve the resources. That is called "encapsulation". It can not be done
perfectly if outside user of abstraction _must_ deal with lifetime (to kill,
close, free, join) underlying precious resources of abstraction. Such
manipulations _can_ still be among operations with abstraction but usage
of those _is not_ among mandatory responsibilities of user of abstraction
anymore thanks to destructors.

I don't see what this has to do with my point. I was on the way to
illustrating destructors without OO to show the other half of my
argument, and I picked resource manage as an example because it is often
cited as a benefit of C++'s object model.

I did nowhere say that destructors (or RAII) can be /only/ used for
OOP. Use how you want. I said that destructor and RAII idiom are very
beneficial feature for OOP features like information hiding,
encapsulation and separation of concerns.

When I say X, it does not mean that you said ~X.

I am painting an alternative picture: one in which destructors can exist
without OO, and in which OO can exist without destructors.

Yes. Similarly a pine may be in garden, in park or in forest. Pine is
not forest, pine is tree and there may be forest without pine. However
there can't be forest without trees and pine is good, straight tree in
forest.

So in this analogy destructors=pine trees, object-orientation=forest?
That seems reasonable, up to a point. They are separate concepts, not
intrinsically linked -- you can have one without the other, and vice-versa.

It is like to claim that there are no logical connections between pine and
forest?

Yes, though "logical" is obviously itself being used metaphorically.
Alternatives are "intrinsic", "inevitable", "fundamental", and so on.

World largest forests (see "taiga") are mostly pines, spruces and
larches. So world forests would be _lot_ poorer without those pines.

Have you used Smalltalk? I think you are steeped in the culture of
lexically scoped languages without function-like objects in which the
lifetime of an object assumes greater importance.

 

[Tim Rentsch]

[...]
Object-oriented programming - both the term and the concept -
predates not only C++-style destructors but C++ itself.
Anyone who thinks destructors are part of OOP doesn't
understand the term.

According to the Official Definition of OOP -- which exists where,
exactly?

Quoting https://en.wikipedia.org/wiki/Object-oriented_programming -

The Smalltalk language, which was developed at Xerox PARC
(by Alan Kay and others) in the 1970s, introduced the term
/object-oriented programming/ to represent the pervasive use
of objects and messages as the basis for computation. [...]
Smalltalk and with it OOP were introduced to a wider
audience by the August 1981 issue of Byte Magazine.

I think it is fair to say that these statements represent the
generally accepted view in the Computer Science community.

I don't know about that. In the past, there was another view based off
the SIMULA language (as pointed out elsethread). I suspect, if it's
been settled at all, that it's currently an amalgamation of the two
views.

The adjective "object-oriented" was applied to Simula only
after it appeared in papers talking about Smalltalk. I
don't think there is any serious disagreement that the term
"object-oriented programming" originated with Alan Kay more
or less at the inception of doing Smalltalk (possibly a year
or two earlier when he was writing his thesis on the Dynabook).
Certainly some of the key ideas were present in earlier systems,
notably Sketchpad which predates even Simula, but it was Kay
who coined the term and first articulated the approach as a
general programming paradigm. Simula was dubbed an object-
oriented language only afterwards, because it has classes.
The point of the quoted paragraph is not where the ideas
were first seen but where the term originated and who first
articulated a meaning for it.

 

[Öö Tiib]

The number 42. In Smalltalk, numbers are objects and respond to message
like any other. I think you have decided that objects must correspond
to things in "real life" (is a number such a thing? I don't know) and
that they must have a "death" that the programmer in charge of. You
may, in other words, be defining the term so that a destructor plays a
central role.

If we discuss values as objects (as immutable everlasting objects) then yes,
we never need to construct or destroy or modify integer value 42 or string
literal "42". So while it can be amusing to consider them (and the bits they
consist of) as objects too the purpose of OOP is not to dig into bits but to
abstract away AFAIK.

I don't see what this has to do with my point. I was on the way to
illustrating destructors without OO to show the other half of my
argument, and I picked resource manage as an example because it is often
cited as a benefit of C++'s object model.

It clarifies mine point. The benefit is not resource management (that is good
but everybody need to do it regardless of paradigm) but better encapsulation
(that is OOP).

When I say X, it does not mean that you said ~X.

Fair enough.

I am painting an alternative picture: one in which destructors can exist
without OO, and in which OO can exist without destructors.

Destructors are feature that I miss the most in OOP languages that lack them.
Unlike generic programming that is different paradigm (and that I also miss) the
destructors are special methods of class of object. Method is OOP term. So
while using destructors as strange functions that are called when variable goes
out of scope is fine (do what you want, your tools) it is not by design. Itis like
using the templates of C++ for compile-time metaprogramming. It is possible
since the template system of C++ is Turing-complete (and again do what you
want) but ... hell, it looks awful and unmaintainable mess when done.

So in this analogy destructors=pine trees, object-orientation=forest?
That seems reasonable, up to a point. They are separate concepts, not
intrinsically linked -- you can have one without the other, and vice-versa.


Yes, though "logical" is obviously itself being used metaphorically.
Alternatives are "intrinsic", "inevitable", "fundamental", and so on.


Have you used Smalltalk? I think you are steeped in the culture of
lexically scoped languages without function-like objects in which the
lifetime of an object assumes greater importance.

I tried. Results did perform 10 times worse than C. I was terrified when
people said that this is normal, by design. How can it compete? So I
dropped it. What does Smalltalk do with objects like thread, network
connection, file descriptor, communication port or connected USB or
Bluetooth device? Such are precious resources and precise monitoring
and management of life-time of such is important. In C++ OOP one
can make it responsibility of single object and so abstract that concern
away from rest of the code.

C++ performs as well as C, has most of C features (some unneededly
even IMO) and has number of additional useful features so that excuses
the warts (some unfortunate features) for me, YMMV.

 

[Tim Rentsch]

It seems Simula [0] wins for first object oriented computer
language. Even the inventor of C++ Bjarne Stroustrup talks
about Simula this way [1] [2] and influencing his worldview.

There is no question that Simula 67 has classes and inheritance,
and also predates Smalltalk. Calling it the first object-oriented
language, however, is historical revisionism - the term "object-
oriented programming" didn't exist until Alan Kay coined it, and
the standalone adjective "object-oriented" came along only after
that. Moreover it misses a key point - whether a program is
"object-oriented" is not determined by the presence or absence of
certain language features, any more than functional programming is
determined by whether or not a language has functions. Certainly
it is possible to do object-oriented programming in Simula, but
it's also possible in FORTRAN; I have done both.

[examples of OO systems in non-OO languages]

Even so, I am not convinced one can say that no language was
necessarily "object oriented" before the term was invented to
describe it.

The question is not which system first supported or displayed
characteristics of object-oriented programing, but from whence
the term originated and hence was defined. For all I know the
people who developed Simula may have been doing what is now
termed object-oriented programming, and if so more power to
them, but they did not originate the term.

I have the "Handbook of Programming Languages" including vol. 1
(Object-Oriented Languages).

The hereditary graph on the OO side starts with Simula, but there
is no Simula chapter. In the introduction:

"SIMULA 67 was the first example of using classes of objects.
The first truly object-oriented programming language was
Smalltalk named in 1971."

Seems to me one can use the "True Scotsman" analogy here.
Simula was Object-Oriented, but not truly Object-Oriented.

This is a misuse of language. By themselves programming
langauges are neither object-oriented nor non-object-oriented.
A programming language may provide good support for doing
object-oriented programming, which Simula certainly does,
but that doesn't mean Simula defines or helps define what
constitutes "object-oriented programming"; that was done by
Alan Kay and the other people who did Smalltalk.