Pure OO-What differentiates a true OO from object-based systems
Thieu Lequang
Smalltalk is considered to be the purest in OO. Can any body clarifies
what differentiates a true OO from obect-based systems? Thieu
Ell
: In article <DJ66q...@on.bell.ca> leq...@qc.bell.ca (Thieu Lequang) writes:
:
:
: Several develoment tools on the market claim to be Object--Oriented.
: Smalltalk is considered to be the purest in OO. Can any body clarifies
: what differentiates a true OO from obect-based systems? Thieu
Support for abstraction, encapsulation, and polymorphism are among the
generally agreed core of OO and an OOPL. Generall object based
langauges, or systems don't support easy polymorphism.
By that token C++ as well as Smalltalk are OOPLs.
:...
: None of these claims make any sense to me. For my money, purity is a
: "non issue". What *is* an issue is *usability*.
By this criteria most present day assembly languages are OOPLs. And
things can be more, or less usable, what kind of criteria is for an OOPL?
This is an excellent display of bad philosophical pragmatism.
Elliott
Robert C. Martin
Several develoment tools on the market claim to be Object--Oriented.
Smalltalk is considered to be the purest in OO. Can any body clarifies
what differentiates a true OO from obect-based systems? Thieu
There is no good definition for exactly what OO is. Therefore there is no
good definition for what "pure" OO is. The term is meaningless.
Some contend that Smalltalk is "pure" becuase since everything in
Smalltalk is an object, it forces you to write OO code. This is
nonsense. You can write very nice procedural code in Smalltalk.
Some will claim that Eiffel is pure because it has "program by
contract" and "Garbage Collection", but who ever said these things
were constituents of OO?
Some will claim that C++ is not pure because it is a "hybrid" language
(whatever that means).
None of these claims make any sense to me. For my money, purity is a
"non issue". What *is* an issue is *usability*. I find tools like
Rose, or SCase quite adequate for assisting in the design and
implementation of OO applications.
--
Robert Martin | Design Consulting | Training courses offered:
Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
14619 N. Somerset Cr| Tel: (708) 918-1004 | Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.
Suresh Vaidyanathan
>
>By this criteria most present day assembly languages are OOPLs. And
>things can be more, or less usable, what kind of criteria is for an OOPL?
>This is an excellent display of bad philosophical pragmatism.
>
In your eagerness towards ad-homineum attack and recitation of
platitudes [omitted here], you have missed the point of the original
discussion which was to do with the concept of "purity" of OO languages.
>Elliott
Ell
: In article <DJ66q...@on.bell.ca> leq...@qc.bell.ca (Thieu Lequang)
: : Several develoment tools on the market claim to be Object--Oriented.
: : Smalltalk is considered to be the purest in OO. Can any body clarifies
: : what differentiates a true OO from obect-based systems? Thieu
: generally agreed core of OO and an OOPL. Generall[y] object based
I would venture to say that it is mostly support for "abstraction", _and
easy "polymorphism"_, which really constitute the "core" of an
object-oriented programming language (OOPL). Object based languages only
offer support for "abstraction". And this is the significant "deficit" of
object based languages, the inability to easily specify varying
implementation off of a more general structural concept.
Elliott
Ell
: Robert C. Martin (rma...@oma.com) wrote:
: :...
: : None of these claims make any sense to me. For my money, purity is a
: : "non issue". What *is* an issue is *usability*.
: things can be more, or less usable[.] [W]hat kind of criteria is [this]
: for an OOPL?
Elliott
Ell
: In article <4a7toe$2...@news4.digex.net>, Ell <e...@access1.digex.net> wrote:
: >
: >By this criteria [usability] most present day assembly languages are
: >OOPLs. And
: >things can be more, or less usable, what kind of criteria is for an OOPL?
: In your eagerness towards ad-homineum attack and recitation of
: platitudes [omitted here], you have missed the point of the original
: discussion which was to do with the concept of "purity" of OO languages.
: Suresh Vaidyanathan
You conveniently elided the beginning of my response which very much
addressed the concerns of the original poster and throws my above
comments into the proper light.
Elliott
Jon S Anthony
> Robert C. Martin (rma...@oma.com) wrote:
> : In article <DJ66q...@on.bell.ca> leq...@qc.bell.ca (Thieu Lequang)
> : writes:
> :
> :
> : Several develoment tools on the market claim to be Object--Oriented.
> : Smalltalk is considered to be the purest in OO. Can any body clarifies
> : what differentiates a true OO from obect-based systems? Thieu
>
> Support for abstraction, encapsulation, and polymorphism are among the
> generally agreed core of OO and an OOPL. Generall object based
> langauges, or systems don't support easy polymorphism.
Unfortunately, your comments indicate how easy it is to trip up. You
really want to say "dynamic polymorphism". Leaving it unqualified isn't
"good enough" as generics/templates give static polymorphism and they
support it just fine (and "easy").
> By that token C++ as well as Smalltalk are OOPLs.
As would Ada83...
> : None of these claims make any sense to me. For my money, purity is a
> : "non issue". What *is* an issue is *usability*.
>
> By this criteria most present day assembly languages are OOPLs. And
> things can be more, or less usable, what kind of criteria is for an OOPL?
>
> This is an excellent display of bad philosophical pragmatism.
Perhaps. But being sloppy doesn't do much good either.
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
Jacob Gore
> Some contend that Smalltalk is "pure" becuase since everything in
> Smalltalk is an object, it forces you to write OO code. This is
> nonsense. You can write very nice procedural code in Smalltalk.
Procedural programming is one that uses a sequence of side-effects to produce
the desired outcome. Object-oriented programming is a type of procedural
programming.
Smalltalk does force you to write object-oriented code. It does not force
you to write well-designed object-oriented code: you could create an object
called "system" and have the whole system implemented as one enormous method
called "run" (I'd venture to guess this is an example of what you mean by
"very nice procedural code", right?).
> Some will claim that Eiffel is pure because it has "program by
> contract" and "Garbage Collection", but who ever said these things
> were constituents of OO?
Hmmm....I've never seen that claimed. Eiffel is purely object-oriented
because everything in Eiffel is an object -- same as Smalltalk.
Programming by Contract is an inheritance discipline driven by certain
aspects of abstraction. It is not essential for code to be considered
object-oriented, but it helps improve object-oriented code. I don't see how
a non-object-oriented language could support Programming by Contract, so I
would consider its support an indication that the language is O-O; but it
says nothing about its purity.
Garbage collection is not essential for OO. However, not having garbage
collection makes it very difficult to use functions which create objects
inside expressions -- in other words, lack of garbage collection cramps your
style. It also adds much opportunity for error to the program, since keeping
track of what needs to be deallocated when is very difficult.
> Some will claim that C++ is not pure because it is a "hybrid" language
> (whatever that means).
It means that it is possible to have data entities that are not objects:
entities which are not encapsulated and are thus very vulnerable to types of
changes that were not intended by their designer.
> None of these claims make any sense to me. For my money, purity is a
> "non issue". What *is* an issue is *usability*. I find tools like
> Rose, or SCase quite adequate for assisting in the design and
> implementation of OO applications.
When my programmers already have solid object-oriented programming habits, I
don't care if the language is pure or hybrid. When they are just crossing
over... oh boy. Same goes for teaching undergraduates: if you are teaching
object-oriented programming, use a pure language and save yourself and your
students a lot of misery.
Of course, good design tools are great to have too. If your situation is
such that the design tool will generate purely object-oriented source for
you, it does not matter if the target language is hybrid or pure (as long as
the generated source is not subsequently messed up during manual editing).
Jacob
---
Jacob Gore, Eastern NM U. Jacob...@Math.ENMU.Edu | Ja...@ToolCASE.Com
Bertrand Meyer
[Quoting Robert Martin]
||| Some will claim that Eiffel is pure because it has "program by
||| contract" and "Garbage Collection", but who ever said these things
||| were constituents of OO?
[Jacob Gore's answer:]
> Hmmm....I've never seen that claimed.
Now you have. I for one definitely consider Design by Contract (as I now
prefer to call it) and garbage collection to be essential constituents of
any serious use of object technology.
Design by Contract, summarized in five lines, states that one should not write
a class without a specification - a contract. The contract lists the internal
consistency conditions that the class will maintain (the invariant) and, for each
operation, the correctness conditions that are the responsibility of the client
(the precondition) and those which the operation promises to establish in return
(the postcondition).
Writing a class without its contract would be similar to producing an
engineering component (electrical circuit, VLSI chip, bridge, engine...)
without a spec. No professional engineer would even consider the idea.
Nor would a customer; who would buy an amplifier without a technical,
specification listing the external, implementation-independent properties
of the device, such as acceptable input voltages (the equivalent of a precondition),
the resulting output voltages (postcondition), the temperature range (invariant)?
The basis of object-oriented development is abstractly defined object
types (classes); one cannot conceive of a class without an abstract
specification - the contract.
This is not someone's pet idea; it is an integral part of the technology.
That many people try to do O-O development - using Smalltalk, C++,
Delphi, Booch, use cases, whatever - without having the slightest idea of
this requirement is a reflection on what they have been taught as
``object-oriented '', on the intellectual limitations of the methods and tools
they use, and on the youth of the field; it does not make Design by Contract
less central to the technology.
So much for Design by Contract. As to garbage collection, which should really
be called automatic memory management for this discussion, the necessity
follows from the dynamic model promoted by object-oriented software
construction. Almost daily, someone writes on comp.object that one of the
attractions of object technology is its modeling power - an accurate comment.
But then if you start writing O-O systems that model the complexity
of real systems and perform advanced operations on these models,
you will in almost all cases create myriads of objects at execution time,
with complex relations between them. This is a direct consequence of the
technology, and a favorable one - a testimonial to how the method enables us
to describe *complex* dynamic phenomena through *simple* static structures
(the structures of our O-O programs). If you have to manage the allocation and
deallocation of these objects manually, you lose almost all these advantages:
horrendous complexity creeps back in.
Manual memory management - that is to say, the absence of automatic
garbage collection - suffers from two fatal flaws: it is *dangerous*
(as it is all too easy to make a mistake, causing errors that are often missed
during testing and arise only when the system goes operational, usually in an
erratic and hard-to-reproduce conditions); and it is extremely *tedious*,
forcing the developer to concentrate on mundane yet complex tasks of bookkeeping
and garbage collection instead of working on their application. These
deficiencies are bad enough to cancel out any benefit that is claimed for the
application of object-oriented techniques.
Only toy object-oriented developments can afford not to rely on automatic
memory management. That some of the object-oriented literature ignores this
aspect, or dismisses it as a lowly implementation concern, does not make it
less essential.
It is really frustrating to B.O.N. and Eiffel developers - who alone can rely
on Design by Contract and garbage collection as built-in facilities
in their method, language and environment - to have to defend these
points forever. (Not with Jacob Gore, of course; my difference of
appreciation with him is minor.) Once you have started to develop
systems by relying on these mechanisms you find it impossible to go back,
and hard to understand why others still argue with the obvious.
This is perhaps what may make Eiffel practitioners sometimes appear too
self-confident in forums such as this one. Ideally, one should perhaps have
infinite patience with people who do not understand the benefits of modern
technology, and who accuse you of arrogance for asserting these benefits.
But how far does one go?
Although I have not read the historical record, I am pretty sure that in
their discussions with proponents of Roman numerals the people who had found
out how to do arithmetic with Arabic numerals were once in a while,
and perhaps fairly in a few cases, accused of arrogance too, or of being
religious zealots unable to listen to the arguments of the other side.
Arrogant they might have been, but, more importantly in retrospect,
they were right.
--
Bertrand Meyer, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bert...@eiffel.com> - ftp://ftp.eiffel.com
Web home page: http://www.eiffel.com
Temporarily at SOL, Paris. Please use usual e-mail address.
[The "lapel pin" [++] indicates adherence to the SELF-DISCIPLINE program
for better Usenet discussions. See http://www.eiffel.com/discipline.]
Joe Borkoles
[lots of stuff re design by contract snipped here]
I do not know the origin behind these views, but
I can say that I sympathise, certainly memory leaks
in C++ can be tedious, (I find multiple deletes less
serious and using unallocated objects even less). Generally
style guides and tools address these problems.
However I have been using tools for over 3 years now
that make this much less of a chore, so much so that
it really doesn't bother me too much. That is I try and
make the owner of a piece of memory very clear in the
design stage and avoid the 'complexity' of having to clean
up myself. In addtion the tools, like SmartHeap, MFC
diagnostics etc. report instantly when a leak or
other memory error occurs and I can fix it straight away
- no hassel. This means that it is no longer problematic
and it gives me very fine grained control when I need it.
Nice! Also I believe that a GC lib could be attached to C++
if the need were great enough. Certainly GC is not 'essential'
for OO. My Smalltalk and Actor experience did leave
a pleasant taste in my mouth re GC but at the end of the day
I find thiniking clearly about ownership in a design can enhance
it and GC really has ceased to become a problem.
For me the defining features of an object oriented style are that it
must support:
Abstraction
Encapsulation
Polymorphism
Inheritance.
No more and no less.
As for design by contract it is not OO only, defining pre- and post-conditions
is good practice whatever style of programming one is engaged in.
Johnston Ian (by ubsswop)
|> From Jacob Gore <jacob...@math.enmu.edu>:
|>
|> [Quoting Robert Martin]
|> ||| Some will claim that Eiffel is pure because it has "program by
|> ||| contract" and "Garbage Collection", but who ever said these things
|> ||| were constituents of OO?
|>
|> [Jacob Gore's answer:]
|>
|> > Hmmm....I've never seen that claimed.
|>
|> Now you have. I for one definitely consider Design by Contract (as I now
|> prefer to call it) and garbage collection to be essential constituents of
|> any serious use of object technology.
|>
|> Design by Contract, summarized in five lines, states that one should not write
|> a class without a specification - a contract. The contract lists the internal
|> consistency conditions that the class will maintain (the invariant) and, for each
|> operation, the correctness conditions that are the responsibility of the client
|> (the precondition) and those which the operation promises to establish in return
|> (the postcondition).
I agree that Design By Contract is an essential constituent of software
engineering. Is it unique to object technology though?
[...]
|> So much for Design by Contract. As to garbage collection, which should really
|> be called automatic memory management for this discussion, the necessity
|> follows from the dynamic model promoted by object-oriented software
|> construction. Almost daily, someone writes on comp.object that one of the
|> attractions of object technology is its modeling power - an accurate comment.
|> But then if you start writing O-O systems that model the complexity
|> of real systems and perform advanced operations on these models,
|> you will in almost all cases create myriads of objects at execution time,
|> with complex relations between them. This is a direct consequence of the
|> technology, and a favorable one - a testimonial to how the method enables us
|> to describe *complex* dynamic phenomena through *simple* static structures
|> (the structures of our O-O programs). If you have to manage the allocation and
|> deallocation of these objects manually, you lose almost all these advantages:
|> horrendous complexity creeps back in.
|>
|> Manual memory management - that is to say, the absence of automatic
|> garbage collection - suffers from two fatal flaws: it is *dangerous*
|> (as it is all too easy to make a mistake, causing errors that are often missed
|> during testing and arise only when the system goes operational, usually in an
|> erratic and hard-to-reproduce conditions); and it is extremely *tedious*,
|> forcing the developer to concentrate on mundane yet complex tasks of bookkeeping
|> and garbage collection instead of working on their application. These
|> deficiencies are bad enough to cancel out any benefit that is claimed for the
|> application of object-oriented techniques.
What I find difficult to understand is why memory management is singled
out as something that should be handled by the system. Why does this not
apply to, say, file handles, network connections, GUI windows, or other
resources?
|> Only toy object-oriented developments can afford not to rely on automatic
|> memory management. That some of the object-oriented literature ignores this
|> aspect, or dismisses it as a lowly implementation concern, does not make it
|> less essential.
|>
|> It is really frustrating to B.O.N. and Eiffel developers - who alone can rely
|> on Design by Contract and garbage collection as built-in facilities
|> in their method, language and environment - to have to defend these
|> points forever. (Not with Jacob Gore, of course; my difference of
|> appreciation with him is minor.) Once you have started to develop
|> systems by relying on these mechanisms you find it impossible to go back,
|> and hard to understand why others still argue with the obvious.
I understand the feeling that it is impossible to go back once you have
used these mechanisms; that's the way I feel about OO technology in general.
However, what you have to understand is that some people are nervous about
garbage collection because it is not necessarily available under all
circumstances. Even if you are using Eiffel, or any other language which
provides automatic memory management, you might be interfacing with external
modules which do *not* provide such memory management. If one of these modules
leaks memory, then your application leaks memory. Let's say you use RPCs.
The client will allocate memory on your behalf when result sets are returned
from the server. You have to ensure that this memory is released: nobody
will do it for you. Simply to say "use language X and you are freed from
managing memory" is just not realistic (unless your entire application is
implemented in language X).
This is not to say that garbage collection is a bad thing per se. However,
to dismiss arguments against garbage collection -- "to defend these points
forever" -- does not take account of the realities of most development
environments (interfacing to external legacy code) nor does it answer the
question as to why memory management should benefit from automation when
other resource management does not. In addition, proponents of automatic
resource management need to be able to devise suitable finalisation techniques
for all sorts of different types of resource. This problem currently seems
to be ignored (i.e. "automatic memory management is enough").
BTW. I enjoy your writings very much. In particular, OOSC was an eye opener
for me when I first read it.
Ian
Piercarlo Grandi
>>> On 11 Dec 1995 16:26:37 GMT, j...@ubszh.net.ch (Johnston Ian (by
>>> ubsswop)) said:
Johnston> In article <1...@feiffel.UUCP>, bert...@feiffel.UUCP (Bertrand
Johnston> Meyer) writes:
Bertrand> [ ... ] Now you have. I for one definitely consider Design by
Bertrand> Contract (as I now prefer to call it) and garbage collection
Bertrand> to be essential constituents of any serious use of object
Bertrand> technology. [ ... ]
Johnston> I agree that Design By Contract is an essential constituent of
Johnston> software engineering. Is it unique to object technology
Johnston> though?
Obviously not: it is nothing else than old good Dijkstra style designing
programs so that you know they are correct (A Discipline of
Programming), with specific recommendation for a modular/OO language.
But, here I note that Meyer writes "any serious use of object
technology". Now as to this one cannot but agree: for this is just a
special case of "any serious use of software technology".
Meyer's statement as written is precisely focused, and does _not_ imply
that:
* design discipline is as such part of the definition of OO,
but only an essential constituents of its serious _use_.
* design discipline is exclusive to OO either.
As I read it it says whatever OO design is, design discipline must be an
essential part of the practice of deploying it in non-toy projects.
Bertrand> [ ... ] So much for Design by Contract. As to garbage
Bertrand> collection, which should really be called automatic memory
Bertrand> management for this discussion, the necessity follows from the
Bertrand> dynamic model promoted by object-oriented software
Bertrand> construction. [ ... ] Only toy object-oriented developments
Bertrand> can afford not to rely on automatic memory management.
Again here I see a precise focus: that automatic storage management is a
_practical_ necessity. Again I see here that the claim is that this
technique too is a practical necessity for programming in the large,
rather than specifically programming in the large with OO. It does not
exclude that it is a necessity also for non-toy traditional systems.
Johnston> What I find difficult to understand is why memory management
Johnston> is singled out as something that should be handled by the
Johnston> system.
Ah, as to this I can offer several compelling reasons. The most
compelling one is that the _whole_ of a program's correctness depends on
that of storage reclamation, and this is simply not true of:
Johnston> Why does this not apply to, say, file handles, network
Johnston> connections, GUI windows, or other resources? [ ... ]
If the programmer bungles storage reclamation everything is affected.
Therefore the best bet, _unless the programmer knows better_, is to
reuse a storage manager that is known to be reliable.
Consider this: every single delete (or whatever) written by the
programmer has the potential to be wrong, and provingcorroborating the
notion that no such 'delete' is improper, and all 'deletes' that should
be there are there, is an amazingly subtle task. Taking risks as to this
all over a large program should not be the default choice, should only
be the case when compelling practical reasons demand it.
Note that in most languages storage _allocation_ is already managed
automatic by a reusable library (the 'malloc' library in C for example),
and exactly for the same reasons for which storage reclamation should
also be automatic: because writing a correct storage management scheme,
whether it be allocation or reclamation, is quite hard, its mistakes
impact the reliability of the whole program, and besides it is not what
an application programmer is supposed to reinvent every time (unless
there is a _truly_ compelling reason to do so, of course) an application
is written.
Bertrand> That some of the object-oriented literature ignores this
Bertrand> aspect, or dismisses it as a lowly implementation concern,
Bertrand> does not make it less essential.
This is indeed true, but let me defend that literature: it _is_ a lowly
implementation concern, after all :-), that's precisely the reason why
an automatic one should be used, and while it is essential in a
practical sense, it is not quite uniquely essential to OO.
Bertrand> It is really frustrating to B.O.N. and Eiffel developers - who
Bertrand> alone can rely on Design by Contract and garbage collection as
Bertrand> built-in facilities in their method, language and environment
A little plug, eh? -- but a bit excessive. Let's say that other systems
have assertions of various sorts, and those present in Eiffel don't
quite amount to building in Design by Contract, just providing _minimal_
support for _some_ of it. Otherwise Eiffel would be Alphard or Euclid,
which would not be that good an idea.
Johnston> [ ... ] However, what you have to understand is that some
Johnston> people are nervous about garbage collection because it is not
Johnston> necessarily available under all circumstances. [ ... ]
Well, let's say that if that were the point, too bad for those
circumstances.
The better point is that it is not _desirable_ under all circumstances,
but those are so rare (mostly related to dire system programming
projects) that they should be a carefully justified exception, not the
default.
It is a bit like programming in assembler: using a compiler avoids a lot
of little stupid mistakes that can make the whole program incorrect
(e.g. not spilling a register when one should), because one can rely on
the compiler getting the little details of code management right more
reliably than most programmers can without paying undue attention to
details that are too low level to be really part of the job of
developing applications. Naturally in some cases there is justification
for rolling your own assembler code, as there is for rolling your own
memory management, but the risks of doing so are usually larger than the
payoff.
Johnston> Simply to say "use language X and you are freed from managing
Johnston> memory" is just not realistic (unless your entire application
Johnston> is implemented in language X).
Ah, well Meyer has to pay the bills too :-). On the other hand there are
many, many languages with automatic memory management, and there are
_excellent_ freeware solutions for some popular ones, like C and C++,
that work with most implementations without much of a problem.
There is even a bit of literature that shows that gc even in C/C++ can
often result in performance _improvements_ over manual allocation
(simply because doing manual storage management usually means user
programmed reference counting, and that is unbelievably expensive,
especially on modern CPUs).
As soon as I find a bit of time I'd like to link the XFree86 X server
with the PARC gc library. I am fairly confident that it will run as
fast as, or faster, than with malloc/free and it will cure whatever
leaks have been the bane of X servers all over the place. One problem
is that here and there the X server denotes resources by ID instead of
address, but since all those IDs go thru pointer tables in the end
this should not be a big problem.
Johnston> [ ... ] In addition, proponents of automatic resource
Johnston> management need to be able to devise suitable finalisation
Johnston> techniques for all sorts of different types of resource. This
Johnston> problem currently seems to be ignored (i.e. "automatic memory
Johnston> management is enough").
Now, now, this is the embarassing little secret of automatic memory
management. The problem is that supporting finalisation has some known
solutions, from the Lisp culture, for example, _but they really require
compiler/implementation support_, and this does not sit well with the
idea of using the above mentioned freeware transparent gc libraries. So
hush, hush :-).
Beside, more seriously, finalization is a difficult _conceptual_
problem, regardless of whether memory management is manual or automatic.
A large amount of the complexity of C++ for example lies in figuring out
just when the destructors for a value are going to be invoked.
Scott Wheeler
>Robert C. Martin writes
>> Some will claim that Eiffel is pure because it has "program by
>> contract" and "Garbage Collection", but who ever said these things
>> were constituents of OO?
>
object-oriented
>because everything in Eiffel is an object -- same as Smalltalk.
Meyer does claim that GC (and multiple inheritance) are essential parts
of OOP in the Red Book Who's Name Escapes Me (sorry - it's the OOP and
D book) - i.e. no language that does not support them is OO. I don't
think he said (there) that programming by contract was part of the
definition. It does seem a little quixotic, but don't let it put you
off Eiffel.
Scott
John DiCamillo
[snip]
>It is really frustrating to B.O.N. and Eiffel developers - who alone can rely
>on Design by Contract and garbage collection as built-in facilities
>in their method, language and environment - to have to defend these
>points forever. (Not with Jacob Gore, of course; my difference of
>appreciation with him is minor.) Once you have started to develop
>systems by relying on these mechanisms you find it impossible to go back,
>and hard to understand why others still argue with the obvious.
With all due respect, I have yet to hear anyone argue that
design by contract and automated memory management are not
useful, just that they are not part of the "conventional"
definition of "object-oriented technology".
>This is perhaps what may make Eiffel practitioners sometimes appear too
>self-confident in forums such as this one. Ideally, one should perhaps have
>infinite patience with people who do not understand the benefits of modern
>technology, and who accuse you of arrogance for asserting these benefits.
No. No one is arguing the *benefits* (at least, no one
credible that I am aware of). This is about a *definition*.
>Although I have not read the historical record, I am pretty sure that in
>their discussions with proponents of Roman numerals the people who had found
>out how to do arithmetic with Arabic numerals were once in a while,
>and perhaps fairly in a few cases, accused of arrogance too, or of being
>religious zealots unable to listen to the arguments of the other side.
>Arrogant they might have been, but, more importantly in retrospect,
>they were right.
This is an excellent example. Arabic numerals are more
effective for computation that Roman numerals, but *both*
are still *numerals*. (Likewise, Smalltalk is still
"object-oriented" even though it does not support DBC.)
The reason that Eiffel practitioners are seen as arrogant
on this topic is that the definition of object-oriented
technology (encapsulation, abstraction, polymorphism)
existed before the Eiffel language, but Eiffel practitioners
chose to redefine the term to exclude all existing object-
oriented languages. Had a new term been invented (say,
"contract-based object technology") that highlighted the
advantages of Eiffel over existing OOPLs, no one would have
grounds for being offended.
--
ciao,
milo
================================================================
John DiCamillo Fiery the Angels Fell
mi...@netcom.com Deep thunder rode around their shores
Rick Lutowski
>From Jacob Gore <jacob...@math.enmu.edu>:
>
>Design by Contract, summarized in five lines, states that one should not write
>a class without a specification - a contract. The contract lists the internal
>consistency conditions that the class will maintain (the invariant) and, for each
>operation, the correctness conditions that are the responsibility of the client
>(the precondition) and those which the operation promises to establish in return
>(the postcondition).
This is equivalent to Parnas' dictum to design a stable interface. It
is indeed fundamental to information-hiding, which is itself fundamental
to OO. Bertand is correct on this one. The only problem is people
keep changing the names and nomenclature for these concepts. New names
for old and established concepts foster confusion, misunderstanding,
and - yes - unnecessary complexity. Since Parans invented it, I say
he gets to name it, so let's just call it "stable interface design"
and not Design by Contract, which sounds too much like the government
customer _should_ dictate a design to the contractor (which happens too
much as it is!)
>It is really frustrating to B.O.N. and Eiffel developers - who alone can rely
>on Design by Contract and garbage collection as built-in facilities
>in their method, language and environment - to have to defend these
>points forever.
There is another approach possible here - stop defending and start
doing. Actions _do_ speak louder than words. Divert the defensive
energy into producing enough Eiffel code and maybe someday it will
have an ANSI/ISO standard. My beef with OOPLs is that ones with
crappy, obtuse semantics (e.g, c++) and/or "better-by-the-ton" syntax
(e.g., Ada) are standards while perhaps better and more promising
ones (Eiffel?) are left to wander with no formal recognition. This
is one reason I havn't jumped onto an OOPL yet - there are no simple
yet effective _standard_ ones (IMHO). I will not use a non-standard
language, nor will I ever recommend a non-standard language of any
kind regardless of merit otherwise. Those who are sure they have an
OOPL winner should work toward standardization (go on the offensive)
rather than constantly playing defense.
Rick Lutowski
--
+-----------------------------------------------------------------+
| Rick Lutowski o...@iah.com 713-332-7281 |
| Object Access http://www.iah.com/oa/ 713-554-7617 |
| --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- |
| The source for Programmer's Reusable Libraries (TM) oa=OO |
+-----------------------------------------------------------------+
Johnston Ian (by ubsswop)
[...]
|> You are missing the point. It is not that automatic memory management is
|> one of the front-line features of OO technology (any more than stack
|> management is a feature of the ALGOL-derived block-structured languages);
|> it is that the ABSENCE of automatic memory management intrudes upon and
|> can even obstruct the application of OO principles. This means that its
|> presence is very definitely part of OO technology.
Could you elaborate on why the absence of automatic memory management
could obstruct the application of OO principles?
Ian
James McKim
>In Article <1995Dec10....@oasis.enmu.edu> Jacob Gore writes:
>>Robert C. Martin writes
>>> Some will claim that Eiffel is pure because it has "program by
>>> contract" and "Garbage Collection", but who ever said these things
>>> were constituents of OO?
>>
>>Hmmm....I've never seen that claimed. Eiffel is purely
>object-oriented
>>because everything in Eiffel is an object -- same as Smalltalk.
>
>Meyer does claim that GC (and multiple inheritance) are essential parts
>of OOP in the Red Book Who's Name Escapes Me (sorry - it's the OOP and
Object Oriented Software Construction.
>D book) - i.e. no language that does not support them is OO. I don't
>think he said (there) that programming by contract was part of the
>definition. It does seem a little quixotic, but don't let it put you
>off Eiffel.
Programming by Contract is a particular interest of mine and I probably
have rather extreme views on the subject. Consider the following assertions:
1. You practice programming by contract every time you write a routine. That is,
every routine you write has some precondition which must be satisfied
before the routine can safely be called. The weakest possible such condition is
True, which means the routine can be called anytime. Similarly every routine
has some postcondition which describes what the routine accomplishes, assuming
it was called when the precondition was true. Of course the
precondition and postcondition must be communicated to potential users of
the routine so they know when it is OK to call it and what it will accomplish
for them. The problem is that such communication is often ad hoc, buried in
a manual somewhere, or otherwise obscured. The Eiffel language support for
programming by contract encourages programmers to make the contract explicit
and to make it part of the internal class documentation of each routine.
2. Every language that allows you to write comments supports programming by
contract. You can always write the precondition and the postcondition as
comments. Admittedly, this is minimal support and Eiffel provides considerably
more, notably the ability to compile the contract into a runtime check.
I do agree that once you have used a language that provides more than
minimal support for programming by contract it is difficult to go back,
but I do not agree that a language must be able to compile preconditions
and postconditions to be considered object oriented.
>
>Scott
Hope this helps,
-- Jim
--
*------------------------------------------------------------------------------*
Jim McKim (203)-548-2458 Co-editor of Eiffel Outlook
Internet: j...@hgc.edu Subscribe early and often!
Robert C. Martin
Robert C. Martin writes
> Some contend that Smalltalk is "pure" becuase since everything in
> Smalltalk is an object, it forces you to write OO code. This is
> nonsense. You can write very nice procedural code in Smalltalk.
Procedural programming is one that uses a sequence of side-effects
to produce the desired outcome. Object-oriented programming is a
type of procedural programming.
We are having a problem with definitions. Yes, I agree, in that light
OO is procedural. It is conventional in OO circles to refer to
structured design (i.e. a design in which high level functions call
lower level functions, which in turn call lower level functions)
procedural.
Smalltalk does force you to write object-oriented code. It does
not force you to write well-designed object-oriented code: you
could create an object called "system" and have the whole system
implemented as one enormous method called "run" (I'd venture to
guess this is an example of what you mean by "very nice procedural
code", right?).
In part. Actually I was thinking of one great big objects with lots
of data elements and methods defined inside it. Exactly equivalent to
a structured design.
> Some will claim that C++ is not pure because it is a "hybrid" language
> (whatever that means).
It means that it is possible to have data entities that are not
objects: entities which are not encapsulated and are thus very
vulnerable to types of changes that were not intended by their
designer.
By that definition, Smalltalk is a hybrid language, since it is
possible in smalltalk to create unencapsulated data structures.
(i.e. smalltalk objects whose only methods are accessors for their
instance variables.)
> None of these claims make any sense to me. For my money, purity is a
> "non issue". What *is* an issue is *usability*. I find tools like
> Rose, or SCase quite adequate for assisting in the design and
> implementation of OO applications.
When my programmers already have solid object-oriented programming
habits, I don't care if the language is pure or hybrid. When they
are just crossing over... oh boy.
Oh boy -- what? What benefit does "purity" bring to them? What *is*
purity?
Same goes for teaching
undergraduates: if you are teaching object-oriented programming,
use a pure language and save yourself and your students a lot of
misery.
Which pure OOPL? Will everyone agree that it is a pure OOPL?
James McKim
>bert...@feiffel.UUCP (Bertrand Meyer) writes:
>>
>> [snip]
>>
>>on Design by Contract and garbage collection as built-in facilities
>>in their method, language and environment - to have to defend these
>>appreciation with him is minor.) Once you have started to develop
>>systems by relying on these mechanisms you find it impossible to go back,
>>and hard to understand why others still argue with the obvious.
>
>: With all due respect, I have yet to hear anyone argue that
>: design by contract and automated memory management are not
>: useful, just that they are not part of the "conventional"
>: definition of "object-oriented technology".
>
>>This is perhaps what may make Eiffel practitioners sometimes appear too
>>self-confident in forums such as this one. Ideally, one should perhaps have
>>infinite patience with people who do not understand the benefits of modern
>>technology, and who accuse you of arrogance for asserting these benefits.
>
>accusations, and villify people on a personal basis (true, or not) in
>this forum.
I've lost you here. I see no hint of vilification in Bertrand's post.
>
>The Eiffelites have just as much chance to contribute to discussion here
>on comp.object as every one else. While some make their views known in a
Yup. In fact some of us, including Bertrand, were here contributing
meaningfully long before you arrived on the scene. Together, we don't make as
much noise as you, personally, do, in part because we seldom have to
follow up our own posts with clarifications or second thoughts. I haven't
peeked but I'd give even odds that you follow up this post (yours, not my
followup) with some one or two line addition.
>rational, scientific way, we have some of them, who as "bad" Eiffel
>"cultists", one hears very little from in terms of productive discussion.
>What we get from these " bad cultists" is the negativity I mention in the
>above paragraph.
Oh please. I can only think of one person who might fit this description.
Every language has its share of ill advised fanatics and every so often
one of them shows up on the internet for an extended period. In the above,
and in earlier posts, you've made it sound as though such fanatics are
the norm among Eiffel users and I don't appreciate it. In
fact, your last comment along these lines (which I let pass without
comment) was something like, "Maybe there are rational Eiffel users
out there, but they just don't post to this group." I challenge
you to back up these comments by reposting some of the articles you
found offensive. In particular the most prolific posters to this group,
that may be identified as part of the Eiffel Community, over the past five
years have been myself, Richie Bielak, Neil Wilson, Paul Johnson, and
Bertrand Meyer. At least these are the first that come to mind. I particularly
challenge you to find a post from any of the above that merits your branding
him as a "bad Eiffel cultist".
[..]
>
>Elliott
Looking forward to either some evidence or an apology,
Ell
>
> [snip]
>
>on Design by Contract and garbage collection as built-in facilities
>in their method, language and environment - to have to defend these
>points forever. (Not with Jacob Gore, of course; my difference of
>appreciation with him is minor.) Once you have started to develop
>systems by relying on these mechanisms you find it impossible to go back,
>and hard to understand why others still argue with the obvious.
: design by contract and automated memory management are not
: useful, just that they are not part of the "conventional"
: definition of "object-oriented technology".
>self-confident in forums such as this one. Ideally, one should perhaps have
>infinite patience with people who do not understand the benefits of modern
>technology, and who accuse you of arrogance for asserting these benefits.
For you all to make your point there is no need to make false
accusations, and villify people on a personal basis (true, or not) in
this forum.
The Eiffelites have just as much chance to contribute to discussion here
on comp.object as every one else. While some make their views known in a
rational, scientific way, we have some of them, who as "bad" Eiffel
"cultists", one hears very little from in terms of productive discussion.
What we get from these " bad cultists" is the negativity I mention in the
above paragraph.
I think some of the Eiffelites need to make their oo discussion points
and rely on their work and discussion to win the world over to Eiffel.
(I'm guessing that is their goal.)
Elliott
Ell
: bert...@feiffel.UUCP (Bertrand Meyer) writes:
: >
: > [snip]
: >It is really frustrating to B.O.N. and Eiffel developers - who alone can rely
: >on Design by Contract and garbage collection as built-in facilities
: >in their method, language and environment - to have to defend these
: >points forever. (Not with Jacob Gore, of course; my difference of
: >appreciation with him is minor.) Once you have started to develop
: >systems by relying on these mechanisms you find it impossible to go back,
: >and hard to understand why others still argue with the obvious.
: : design by contract and automated memory management are not
: : useful, just that they are not part of the "conventional"
: : definition of "object-oriented technology".
John DiCamillo wrote the last paragraph.
Elliott
Piercarlo Grandi
>>> <sco...@bmtech.demon.co.uk> said:
Scott> In Article <1995Dec10....@oasis.enmu.edu> Jacob Gore writes:
>> Robert C. Martin writes
>>>> Some will claim that Eiffel is pure because it has "program by
>>>> contract" and "Garbage Collection", but who ever said these things
>>>> were constituents of OO?
>> Hmmm....I've never seen that claimed. Eiffel is purely
>> object-oriented because everything in Eiffel is an object -- same as
>> Smalltalk.
Scott> Meyer does claim that GC (and multiple inheritance) are essential
Scott> parts of OOP in the Red Book Who's Name Escapes Me (sorry - it's
Scott> the OOP and D book) - i.e. no language that does not support them
Scott> is OO. [ ... ]
Which is something that I long regretted because just like you I don't
think that concepts like OO should be defined in terms of language
features.
But please note that in the message at the start of this thread Meyer
seems to take a different position, in which his claim is that GC is
essential to serious use of OO, which is a very different idea: it does
not say that it is part of OO (for it then follows that for small-scale
use of OO gc is not essential), and it leaves unsaid that gc is very
useful not just to serious use of OO, but to serious programming in
general.
Edward Xue
>
>What I find difficult to understand is why memory management is singled
>out as something that should be handled by the system. Why does this not
>apply to, say, file handles, network connections, GUI windows, or other
>resources?
>
I think (guess) the final design and implementation goal of "Garbage Collection" is
not limited to memory managment, but a more general purpose which means
"Garbage Object Collection". Hence all resource can be encapsulated in object, and
garbage object collection will provide a solution for all of them.
--
Edward Xue
E-Mail: edw...@sc.mcel.mot.com
Bertrand Meyer
> I agree that Design By Contract is an essential constituent of software
> engineering. Is it unique to object technology though?
Preconditions, postconditions, loop invariants and some other uses of
assertions can be used in non-O-O approaches, although they fit particularly
well with the reuse-focused nature of O-O development. Also, the
anti-defensive-programming nature of Design by Contract (the rule that one
should NOT check for preconditions within a routine) is exactly the reverse
of traditional modes of development - and in fact is shocking to many people
at first, once they fully realize what Design by Contract is about!
Class invariants, on the other hand, only make sense within an O-O approach.
They characterize the semantics of data abstractions - classes -, in terms
of both abstract properties (coming from the ADT specification) and
concrete properties (the representation invariant). I do not know how to
understand or explain the object-oriented method without introducing these
concepts.
In another message John DiCamillo <mi...@netcom.com> writes:
> [...] The definition of object-oriented
> technology (encapsulation, abstraction, polymorphism)
> existed before the Eiffel language, but Eiffel practitioners
> chose to redefine the term to exclude all existing object-
> oriented languages.
As a matter of fact the notions that serve as a basis for Design by
Contract were around, as part of the theoretical basis for
object technology (abstract data types), at least ten years before
O-O ideas reached the masses.
Piercarlo Grandi
>>> Vaidyanathan) said:
Suresh> In article <4a7toe$2...@news4.digex.net>, Ell
Suresh> <e...@access1.digex.net> wrote:
Ell> By this criteria most present day assembly languages are OOPLs.
Ell> And things can be more, or less usable, what kind of criteria is
Ell> for an OOPL? This is an excellent display of bad philosophical
Ell> pragmatism.
Suresh> In your eagerness towards ad-homineum attack and recitation of
Suresh> platitudes [omitted here],
When you accuse somebody of wrongdoing, the last thing you can do is to
write [omitted here]: you ought to provide _evidence_ in the form of
specific examples and explain why they are examples of
wrongdoing. Otherwise we are back to claims like "I have in my pocket a
list of 57 (?) card carrying communists in the State department".
Ell is not one of my favourite posters in comp.object, but at least here
he has not attacked anybody (and from what I remember he does not as a
rule either, so I disagree with your writing "eagerness", which you
state as a fact without providing any evidence).
Suresh> you have missed the point of the original discussion which was
Suresh> to do with the concept of "purity" of OO languages.
And indeed he has not missed the point at all: because he was
criticizing somebody's opinion that purity does not matter, by arguing
that such a position is defeatist.
As to the merit, I think both positions are partially right: for surely
OO is much of an emtpy buzzword, as is my impression that rmartin
argues, but Ell is correct that just leaving it at that is defeatist.
One alternative that agrees with both is to argue that one should
provide specific definitions, for as rmartin argues there is no one
common definition, of OO when one uses the term, for failing to do so is
bad pragmatism as Ell argues, and these should be assessed as to the
consequences of usability, which is important as rmartin argues.
Thus: do provide definitions, for not doing so leaves without a
conceptual goal/guide, but do realize that they are specific and should
be evaluated as to the impact on usability.
R. Kerr
> bert...@feiffel.UUCP (Bertrand Meyer) writes:
> [snip]
> >It is really frustrating to B.O.N. and Eiffel developers - who alone can rely
> >on Design by Contract and garbage collection as built-in facilities
> >in their method, language and environment - to have to defend these
> >points forever. (Not with Jacob Gore, of course; my difference of
> >appreciation with him is minor.) Once you have started to develop
> >systems by relying on these mechanisms you find it impossible to go back,
> >and hard to understand why others still argue with the obvious.
> With all due respect, I have yet to hear anyone argue that
> design by contract and automated memory management are not
> useful, just that they are not part of the "conventional"
> definition of "object-oriented technology".
You are missing the point. It is not that automatic memory management is
one of the front-line features of OO technology (any more than stack
management is a feature of the ALGOL-derived block-structured languages);
it is that the ABSENCE of automatic memory management intrudes upon and
can even obstruct the application of OO principles. This means that its
presence is very definitely part of OO technology.
As far as design by contract is concerned, it is futile to argue whether
this is part of the "conventional" paradigm or not. It is rare for a
paradigm to be so clearly delineated that all issues can be adjuducated to
be categorically within it or without it. There are central central issues
which give the paradigm its identity but there are always others which
support and buttress it (and very likely other paradigms as well) and
willingness to argue whether these "belong" or not is evidence of
narrow-mindedness and bigotry which serves no purpose.
Cheers....Ron
------------------------------------------------------------------------
Ron Kerr, Computing Service, Newcastle University, NE1 7RU, England.
Tel. +44 191 222 8187 Fax. +44 191 222 8765 (NOTE new area code)
------------------------------------------------------------------------
Ell
: In article <4aitke$2...@news4.digex.net> e...@access4.digex.net (Ell) writes:
: >bert...@feiffel.UUCP (Bertrand Meyer) writes:
: >>
: >> [snip]
: >>
: >>It is really frustrating to B.O.N. and Eiffel developers - who alone can
: >>rely
: >>on Design by Contract and garbage collection as built-in facilities
: >>in their method, language and environment - to have to defend these
: >>points forever. (Not with Jacob Gore, of course; my difference of
: >>appreciation with him is minor.) Once you have started to develop
: >>systems by relying on these mechanisms you find it impossible to go back,
: >>and hard to understand why others still argue with the obvious.
: >: With all due respect, I have yet to hear anyone argue that
: >: design by contract and automated memory management are not
: >: useful, just that they are not part of the "conventional"
: >: definition of "object-oriented technology".
: >>This is perhaps what may make Eiffel practitioners sometimes appear too
: >>self-confident in forums such as this one. Ideally, one should perhaps have
: >>infinite patience with people who do not understand the benefits of modern
: >>technology, and who accuse you of arrogance for asserting these benefits.
(Ell)
: >For you all to make your point there is no need to make false
: >accusations, and villify people on a personal basis (true, or not) in
: >this forum.
(JM)
: I've lost you here. I see no hint of vilification in Bertrand's post.
Right, I was not speaking of "Bertrand's" post.
(Ell)
: >The Eiffelites have just as much chance to contribute to discussion here
: >on comp.object as every one else. While some make their views known in a
(JM)
: Yup. In fact some of us, including Bertrand, were here contributing
: meaningfully long before you arrived on the scene. Together, we don't make as
: much noise as you, personally, do, in part because we seldom have to
: follow up our own posts with clarifications or second thoughts. I haven't
: peeked but I'd give even odds that you follow up this post (yours, not my
: followup) with some one or two line addition.
I make no apologies for clarification, which enhances discussion.
Everyone should do it, if they feel it's necessary.
(Ell)
: >rational, scientific way, we have some of them, who as "bad" Eiffel
: >"cultists", one hears very little from in terms of productive discussion.
: >What we get from these " bad cultists" is the negativity I mention in the
: >above paragraph.
(JM)
: Oh please. I can only think of one person who might fit this description.
Yes, one notorious cultist.
: Every language has its share of ill advised fanatics and every so often
: one of them shows up on the internet for an extended period. In the above,
: and in earlier posts, you've made it sound as though such fanatics are
: the norm among Eiffel users and I don't appreciate it.
Please show from my posts how I have said "most" who promote Eiffel are
"such fanatics".
: In
: fact, your last comment along these lines (which I let pass without
: comment) was something like, "Maybe there are rational Eiffel users
: out there, but they just don't post to this group." I challenge
: you to back up these comments by reposting some of the articles you
: found offensive.
Again, I have not found most Eiffel promoters in comp.object "offensive".
: In particular the most prolific posters to this group,
: that may be identified as part of the Eiffel Community, over the past five
: years have been myself, Richie Bielak, Neil Wilson, Paul Johnson, and
: Bertrand Meyer. At least these are the first that come to mind. I particularly
: challenge you to find a post from any of the above that merits your branding
: him as a "bad Eiffel cultist".
Not necessarily from the above, but oh boy _you do have at least one_.
The kicker is from what I know, Eiffel is a very good OOPL, and you all
have some worthy oo process ideas. Yet negative "religious cultism" can
not be abided by any reasonable individual.
Elliott
R. Kerr
> Could you elaborate on why the absence of automatic memory management
> could obstruct the application of OO principles?
This discussion is a recurring theme in this and related newsgroups and I
have attempted to clarify my views on many occasions. I have just done so
again in a private conversation with Ell arising from my earlier posting.
To save time, I will extract what I wrote to him. On second thoughts I
will include my entire message in an attempt to forestall other enquiries,
particularly those relating to my apparently arrogant use of words like
"bigotry". I hope you don't mind me doing this, Ell.
Cheers....Ron
-------------------------------------------
From nrk Wed Dec 13 14:21:59 1995
Subject: Re: [++] Re: Pure OO-What differentiates a true OO from object-based systems
To: e...@access.digex.net (Ell)
Date: Wed, 13 Dec 1995 14:21:59 +0000 (GMT)
Ell writes:
>
>
> While I see how "automatic memory management" adds to the modern "feel"
> of an oopl, I can't for the life of me see how it is required for an oopl
> beyond abstraction and easy polymorphism (including "metamorphism").
Please excuse me for being pedantic about your use of words here. AMM
does not "add to the modern feel of an OOPL". OOPLs started out with
AMM, some of the modern ones retained it and some others didn't. It is
truer to say that the absence of AMM detracts from the original feel
of OOPLs.
> : As far as design by contract is concerned, it is futile to argue whether
> : this is part of the "conventional" paradigm or not.
>
> Again, while this adds to the "modern feel" on an oopl, I don't think it
> is a part of the base conception of oo in its logical imperative of
> modelling systems.
My feelings are less strong on this other than that DBC can be
regarded as another aspect of interface definition. DBC is closely
related to research done at this university in the 1970s (I was a
member of the team, it so happens). This invented the notion of
"recovery blocks" which was a programming construct which enabled the
specification of the required outcome of operations (by acceptance
tests) accompanied by a variety of implementation alternatives. This
was applicable in the conventional program structures of that period,
the perception and significance of OOP not having properly emerged at
that time.
> : It is rare for a
> : paradigm to be so clearly delineated that all issues can be
> : adjuducated to
> : be categorically within it or without it. There are central central issues
> : which give the paradigm its identity but there are always others which
> : support and buttress it (and very likely other paradigms as well)
>
> Right, and I sincerely to you Ron Kerr, don't see how GC and DBC are
> "essential" to modelling systems. They are addendum, though important
> addendum, imo.
Clearly GC is not essential since many systems are constructed without
it. In simple systems (that does not mean small), particularly those
with a static structure, the absence of GC may not be a serious
impediment. But in complex systems, particularly those of a dynamic
nature, determining the lifespan of an object can become extremely
difficult and then this definitely does become an intrusion. In
effect, the application programmer has to write his own garbage
collector for the tricky parts of the system. It may well be that it
is felt expedient to depart from the intuitive system design in order
to simplify this process. To do that is certainly inconsistent with
OOP principles. Subsequent alteration of the system dynamics could
have drastic effects on this in-board garbage collection.
I made the analogy with stack management in ALGOL-like languages.
Automatic stack management simplifies things considerably but for most
situations like straightforward block/procedure entry/exit this would
not be too hard to do by hand. However, languages of the ALGOL era,
and beyond, permitted non-local goto statements and in many of those
situations manual stack management would have been very difficult.
> : and
> : willingness to argue whether these "belong" or not is evidence of
> : narrow-mindedness and bigotry which serves no purpose.
>
> Well, we are bot making points on the issues, and I in no way feel it is
> "narrow-mindedness and bigotry".
It is certainly not "narrow-mindedness and bigotry" to make points in
a discussion. However, in categorising a paradigm there are agreed
central concepts and grey areas as well. I believe that AMM is a
central issue and I am prepared to be pedantic (but not bigoted, I
hope) about that. However, I am less certain about DBC being an
essential characteristic of OO. I believe it is a useful and important
adjunct to the central principles but am not prepared to waste time
arguing whether it falls inside or outside a black and white
categorisation of OO.
>
> Cheers to you Ron Kerr! You have helped me to understand the essentials
> of OO over the years.
Thank you for th