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 that. I have been in this area for longer than almost
anyone else in the world. That doesn't make me a supreme expert but I
have had much longer than most to mull things over. Moreover, I have
seen this topic go backwards while most others think they have seen it
go forwards. That gives for different perspectives.
Warren Montgomery
>|> 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 obstruct the application of OO principles?
>
>
I'm not the original poster, but I'd like to take a crack at this.
"OO principles" is not to my knowledge well defined, but most
people take that to include composing programs by re-using program
units (objects and classes) with well defined interfaces that hide
the details of an implementation matching the interface. The lack
of automatic memory management interferes with this in several ways:
1) Memory management conventions (i.e. who is responsible for
deleting what and when to do it) must become part of the
interface to objects and classes, adding one more thing to the
list of things the programmer must do right to successfully
re-use something.
2) (more serious) Because different memory management conventions
are possible, differences in memory management can create
incompatibilities that prevent a class from being used in a
particular situation.
3) Because memory is a global resource, failure to manage it
properly can cause any part of the program to fail
unpredicatably. Calling a simple function or object method that
frees some piece of memory twice can cause an unpredicable
failure hours later in some completely unrelated and thoroughly
debugged part of the system that happens to get stuck with a
doubly allocated piece of memory. Yes, memory error checking
tools can reduce the possibility, but the possibility remains.
The presense of system provided automatic memory management removes
this as a concern of the programmer, and removes the possibility
that different classes will do it incorrectly or incompatibly.
The analogy to the importance of stack management to ALGOL derived
languages is very apt. When I worked in assembly language in an
era where subroutine (aka function) linkage was crude and most
"variables" were static areas in memory, recursion was something to
be avoided and multi-threading almost unknown. Dealing with either of
these meant cooking up awkward heap allocation schemes to provide
and manage temporary space. Stack allocation in support of ALGOL
and its friends seemed almost magic, and was widely criticized as
unnecessary and inefficient. (Why waste all that memory and time saving
things that you don't need to?) It quickly became universally
accepted. In C, and other languages of it's ilk, heap management
was rare and used only with great care, and not of great concern to
most programmers (in fact most C programs never free anything). As
others have pointed out, OO programs live on the heap, raising
dynamic memory management from a curious problem of interest only
to gurus, to something that everyone gets to deal with. Automatic
memory management is the implementation technique that makes it as
painless for programmers to deal with as the management of stack
based local variables is in more familiar programming environments.
---
Warren Montgomery
ih4sh!warren or w.a.mon...@att.com
Scott Wheeler
>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.
The which is a far more defensible position, particularly given the way
that the Eiffel Base class library makes good use of it. I'm becoming
convinced of it's usefulness in non-time critical code, though there
are a thousand examples of it not being *essential*.
I just think it's a pity that he laid down the law like that at the
start of the book: on first reading it, I decided he wasn't worth
taking seriously with such dogmatic opinions, whereas it turns out he's
got a lot of useful things to say, and his language design is really
elegant.
Scott
Jon S Anthony
> In article <1995Dec10....@oasis.enmu.edu> Jacob Gore <jacob...@math.enmu.edu> writes:
>
> 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.
From the standpoint of programming language design/"theory", this is
a vexing and unfortunate thing. Just another case of sloppy, ill
conceived terminology becoming "standard" and confusing things.
> 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
Actually, it is worse than that. It begs the question of what an object
is. And from the evidence it looks for all the world that the proposed
definition would be, "You know, the fundamental things expressed in OOPLs",
and the circle is complete...
> 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?
Yes, we are back to square one...
> ...
> Which pure OOPL? Will everyone agree that it is a pure OOPL?
1. Whatever is your (rhetorical) favorite of the day.
2. Not just "no", but "hell no!"...
Matthew B. Kennel
: [...]
: |> 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?
Most 'OO' langauges heavily use objects which exist independently of the
textual variables which 'refer' to them, and do not contain them.
Object oriented langauges typically have the notion of 'identity'; two
variables may refer to the same "thing" a.k.a. "object".
Then, proving that an "object" is no longer useful in a program is harder
and different from showing that a variable (something the programmer writes
in text) is no longer being used.
Is there any "OO" language which exclusively uses 'value objects' with
no aliasing ever permitted?
I think these would be called 'abstract data type' or 'functional'
languages. (And at least for the second, intelligent memory management
remains pretty useful)
: Ian
Jon S Anthony
> Matthew B. Kennel (mbk@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN) wrote:
> (MK)
> : Most 'OO' langauges heavily use objects which exist independently of the
> : textual variables which 'refer' to them, and do not contain them.
>
> Heap created objects should have a manager responsible for them in C++, what
> is the big whoop? ^^^^^^
^^^^^^ is the "big whoop", since a) there is nothing that requires this and
b) typically it is either i) not supplied or ii) incorrect.
> Isn't the only thing that matters is the fact that the object is "no
> longer being" used in terms of GC?
I don't know, I can't figure out what you are trying to say here...
> : Is there any "OO" language which exclusively uses 'value objects' with
> : no aliasing ever permitted?
> :
> : I think these would be called 'abstract data type' or 'functional'
> : languages. (And at least for the second, intelligent memory management
> : remains pretty useful)
>
> Pre-95 Ada is generally considered to be an "abstract data type"
> language. Yet it has pointers listening to "them who does" it.
What does this have to do with the question? WRT the question, I
would "guess" the answer is "no" (or does Haskell fit this???) and
further say that the notion of ADT in this context is irrelevant.
Ell
: : "R. Kerr" <R.K...@ncl.ac.uk> writes:
: : [...]
: : |> 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?
(MK)
: Most 'OO' langauges heavily use objects which exist independently of the
: textual variables which 'refer' to them, and do not contain them.
Heap created objects should have a manager responsible for them in C++,
what is the big whoop?
: Object oriented langauges typically have the notion of 'identity'; two
: variables may refer to the same "thing" a.k.a. "object".
:
: Then, proving that an "object" is no longer useful in a program is harder
: and different from showing that a variable (something the programmer writes
: in text) is no longer being used.
Isn't the only thing that matters is the fact that the object is "no
longer being" used in terms of GC?
: Is there any "OO" language which exclusively uses 'value objects' with
: no aliasing ever permitted?
:
: I think these would be called 'abstract data type' or 'functional'
: languages. (And at least for the second, intelligent memory management
: remains pretty useful)
Pre-95 Ada is generally considered to be an "abstract data type"
language. Yet it has pointers listening to "them who does" it.
Elliott
Jon S Anthony
> I'm not the original poster, but I'd like to take a crack at this.
> "OO principles" is not to my knowledge well defined, but most
> people take that to include composing programs by re-using program
> units (objects and classes) with well defined interfaces that hide
> the details of an implementation matching the interface. The lack
> of automatic memory management interferes with this in several ways:
>
> 1) Memory management conventions (i.e. who is responsible for
> deleting what and when to do it) must become part of the
> interface to objects and classes, adding one more thing to the
> list of things the programmer must do right to successfully
> re-use something.
Disagree. You say this is a necessary condition, but it isn't. While
it is probably true that most components fail in this regard (force the
client to deal with the issue) it is not due to lack of global MM.
> 2) (more serious) Because different memory management conventions
> are possible, differences in memory management can create
> incompatibilities that prevent a class from being used in a
> particular situation.
Possible, but again not necessary (as you agree by using "can").
In fact, I would be surprised if this wasn't a very rare thing - even
in bungled implementations.
> 3) Because memory is a global resource, failure to manage it
> properly can cause any part of the program to fail
> unpredicatably. Calling a simple function or object method that
> frees some piece of memory twice can cause an unpredicable
> failure hours later in some completely unrelated and thoroughly
> debugged part of the system that happens to get stuck with a
> doubly allocated piece of memory. Yes, memory error checking
> tools can reduce the possibility, but the possibility remains.
Disagree. There is no requirement that "memory" (from the view of the
langauge or programmer model) be a global resource. Further, there is
no requirement that it be a "monolithic" resource (which is what you
were probably really trying to get at). Separate classes can have
there own memory pools and this can be tightly controlled via the type
model. Sure, _typically_ this (global and monolithic) is how it is
viewed and used.
Now, as I see it, the real problem isn't that AMM can't be done in
the "standard" OO setting without your typical notion of a global GC,
or that it can't be as efficient (often it can be much _more_ efficient),
or that "version skews" will trip over one another. The real problem is
a) it typically _isn't_ done safely, efficiently and transparently and
b) if it is done this way, it typically requires a lot of wheel reinvention
for each such implementation. Of course, b) has a large effect on a).
And this is where a "standard GC" capability really wins. It replaces
a lot of "should be done"s with "is done"s...
Piercarlo Grandi
Warning: I am not sure if I got all the attributions right because
rmartin's newsposter does not set off quotes with any leader but by
white space only, and this can cause some confusion to my quotation
package (it has already tripped another poster).
rmartin> In article <1995Dec10....@oasis.enmu.edu> Jacob Gore
rmartin> <jacob...@math.enmu.edu> writes:
jacob.gore> Robert C. Martin writes
rmartin> Some contend that Smalltalk is "pure" becuase since
rmartin> everything in Smalltalk is an object,
Actually they are not quite right: for example variables, which could be
objects, are not objects (so for example assignment is not a method and
you cannot have different types of variables).
rmartin> it forces you to write OO code. This is nonsense. You can
rmartin> write very nice procedural code in Smalltalk.
Agreed: if anything one can use blocks with parameters in Smalltalk-80,
that are equivalent to lambdas/functions in other languages.
jacob.gore> Procedural programming is one that uses a sequence of
jacob.gore> side-effects to produce the desired outcome.
I register the most vehement opposition to this definition. The presence
of side effect is not _required_ and does not by itself define
procedural programming. My impression is that procedural is intended as
that type of programming in which the decomposition of a program into
parts happens by subdividing it into layers of procedures.
The variety of procedural programming (according to this, not Jacob's,
definition) in which side effects are forbidden is called functional
programming (simply because many authors and languages use "function" to
denote "procedures" that are side-effect free) and that in which
procedures ar clustered in modules that are based on the ADT principle
is called OO, so I agree with you that:
jacob.gore> Object-oriented programming is a type of procedural
jacob.gore> programming.
even if I don't agree with your definition. Here one problem with your
definition is apparent: according to it, what is commonly called
"functional OO" (where procedures and operations are side-effect-free,
including ``assignment'' _and_ clustered in the OO way) programming cannot
exist.
rmartin> We are having a problem with definitions. Yes, I agree, in
rmartin> that light OO is procedural. It is conventional in OO circles
rmartin> to refer to structured design (i.e. a design in which high
rmartin> level functions call lower level functions, which in turn call
rmartin> lower level functions) procedural.
Which is an (incomplete) description of OO too, in that OO is a variety
thereof, an important one, and one that like the functional variety, has
got its own abbreviated name (for "ADT modularized procedural" for OO
and "side effect free procedural" are mouthfuls).
rmartin> Some will claim that C++ is not pure because it is a "hybrid"
rmartin> language (whatever that means).
jacob.gore> It means that it is possible to have data entities that are
jacob.gore> not objects: entities which are not encapsulated and are
jacob.gore> thus very vulnerable to types of changes that were not
jacob.gore> intended by their designer.
Or, more generally, that it is an OO extension to a non OO language.
rmartin> By that definition, Smalltalk is a hybrid language, since it is
rmartin> possible in smalltalk to create unencapsulated data structures.
I think you are confusing here protection with encapsulation.
rmartin> (i.e. smalltalk objects whose only methods are accessors for
rmartin> their instance variables.)
Indeed. Here are you are merely saying that it is possible in
``Smalltalk'' for a programmer to bypass the default protection
checks.
rmartin> None of these claims make any sense to me. For my money,
rmartin> purity is a "non issue". What *is* an issue is *usability*. I
rmartin> find tools like Rose, or SCase quite adequate for assisting in
rmartin> the design and implementation of OO applications.
jacob.gore> When my programmers already have solid object-oriented
jacob.gore> programming habits, I don't care if the language is pure or
jacob.gore> hybrid. When they are just crossing over... oh boy.
rmartin> Oh boy -- what? What benefit does "purity" bring to them?
Well, I agree with Jacob here: a language that both supports and
enforces the OO paradigm to a high degree will be _definitely_ more
useful than one that is (even potentially) laxer: because its
implementation will then be far less forgiving of inadvertent (or not so
inadvertent) violations of the OO paradigm. For the same reason it is
also useful, even if less so, for those that tend to do it less often
because they already tend to apply it because of practice.
rmartin> What *is* purity?
To me it is the strict and universal support and enforcement of the OO
paradigm. As I have argued in the years past, this is not desirable,
even if it is probably attainable, with some limitations.
jacob.gore> Same goes for teaching undergraduates: if you are teaching
jacob.gore> object-oriented programming, use a pure language and save
jacob.gore> yourself and your students a lot of misery.
rmartin> Which pure OOPL?
As far as I know, none exists: there are some language that have
something near to strict and universal support of the OO paradigm, but
very few have reasonably complete support for its enforcement (while
many will ensure no procedure outside a module accesses the
representation of the type encapsulated by the module, none that I know
requires all procedures inside that module to access that
representation).
rmartin> Will everyone agree that it is a pure OOPL?
This is a different question, and let me say a pointless
one. Conformity is not such a useful concept, in the "real word" or in
computer science...
Frieder Monninger
>
>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.
>
>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.
Following this discussion looks very funny - it seems that people
program O-O just for fun.
I alway thought that the reason for all programming was to solve problems,
i.e. to build systems usefull for someone.
And, as in other technical disciplines there are always two approaches -
the "hacker" approach and the "engineering" approach. This seems to be
to hard - and of course there is a floating region between.
Now, Design by Contract is certainly a characteristic in all engineering
disciplines (take for example social (lawyers), structural & electrical engineers).
Engineers not using clear intefaces are hackers. Thats the definition.
(Using in this context means: using in phases - specifying, writing down,
even, if possible, calculating and of course, checking)
And if the contract (the interface, the static of a plane/skyscraper)
fails, people will go to court to find out who was guilty. I was told
that this does not happen with good design.
Applying OO technology does not change this.
====================
Conclusion: Programming without Design by Contract is hacking.
OO " " " " "
--
Frieder Monninger f...@fm.rhein-main.de
35619 Braunfels-Altenkirchen ++ 49 6472 1449
Germany http://www.serve.com/frieder
Frieder Monninger
>
>Conclusion: Programming without Design by Contract is hacking.
> OO " " " " "
>
happy on his own way. I only prefer to fly in a plane _not_ hacked -
but I life in a house hacked in 1960. It has only 2 floors, rather thick
walls and we have no earthquakes here, so I can life with this ......
Its much better as _no_ house (and it is object oriented, so fixing it
can be done mostly even by myself ;-).
Ell
: >>> On 12 Dec 1995 22:29:55 GMT, rma...@oma.com (Robert C. Martin) said:
:
: Warning: I am not sure if I got all the attributions right because
: rmartin's newsposter does not set off quotes with any leader but by
And added work for the responder to distinguish work for attribution.
Elliott
Ell
: In article Jacob Gore <jacob...@math.enmu.edu> writes:
: 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.
From what I understand, procedural means specifying "how" a task is done
rather than simply "what" is to be done. Some languages like ML, from
what I know of it, say I want "xyz" done, but don't specify how "xyz" is
done.
: 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.
That is not the "structured design" I know about. Good structured design
has appropriate decomposition of the analysis problem into abstractions.
This often means having _many_ abstractions. At least this is what I
learned from Structured systems analysis and design, and '70's on COBOL.
Elliott
Patrick Logan
: Conclusion: [OO] Programming without Design by Contract is hacking.
Agreed 100 percent.
--
Patrick Logan plo...@teleport.com
Patrick Logan
: >
: >Conclusion: Programming without Design by Contract is hacking.
: > OO " " " " "
: >
: Please, no flames
I don't see how anyone who has developed large software systems
could flame this statement. Has anyone never been burned by an
unspecified interface?
--
Patrick Logan plo...@teleport.com
Matthew B. Kennel
: 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
My interpretaton of Meyer's notion of 'object-orientation':
The Eiffel class is the simultaneous locus of
1) assertion (hence the 'contract')
2) implementation.
3) interface
4) aggregation.
5) allocation.
6) reference.
(one object may refers to another entity of a class in total)
There are languages which do not combine all of these notions; for instance
I think one could argue that in Ada95, #2 is somewhat removed from #4 and
#3. However, most things that most reasonable people would call "object
oriented" have most of these in common.
It is the existence of items 5 and 6 which induces the strong desirability of
automatic storage management in Eiffel, and by extension to langauges similar
to Eiffel which allow independent allocation and reference of entities
of a class.
C++ has a much richer/more_confusing (take your pick) notion of #6 (pointers
can point to static variables, stack variables, interior elements of an array,
blah blah blah) which makes automatic storage management an even
more pressing issue.
: ------------------------------------------------------------------------
Robert C. Martin
rmartin> Some will claim that C++ is not pure because it is a "hybrid"
rmartin> language (whatever that means).
jacob.gore> It means that it is possible to have data entities that are
jacob.gore> not objects: entities which are not encapsulated and are
jacob.gore> thus very vulnerable to types of changes that were not
jacob.gore> intended by their designer.
Or, more generally, that it is an OO extension to a non OO language.
If that is the definition, that is fine. However that definition says
nothing whatever about "purity"; or the worth of "hybridity"
vs. "purity". By that definition, Obj-C is hybrid (which many obj-C
people will be very upset to learn.)
There are no good definitions for either "pure OOPL" or "hybrid OOPL".
There is no consensus as to the definitions of either. (as this
thread, and many many others have borne out through the last few years.)
rmartin> What *is* purity?
To me it is the strict and universal support and enforcement of the OO
paradigm. As I have argued in the years past, this is not desirable,
even if it is probably attainable, with some limitations.
That is a fine definition. But not one that is universally agreed
upon. Moreover, it says nothing about whether such a language is
possible.
For example, how does one "enforce" the OO paradigm? Just what *is*
the OO paradigm? If you say the OO paradigm is a paradigm in which
everything is an object, and that this can be enforced by creating
language in which everything is an object; then I will respond by
demonstrating that structured-procedural designs can be implemented in
this language, and are therefore conformant to the OO paradigm by that
definition.
rmartin> Which pure OOPL?
As far as I know, none exists: there are some language that have
something near to strict and universal support of the OO paradigm, but
very few have reasonably complete support for its enforcement (while
many will ensure no procedure outside a module accesses the
representation of the type encapsulated by the module, none that I know
requires all procedures inside that module to access that
representation).
Is this what "enforcement" means? Methods of a class must access its
own members through accessor methods? If so, does this also define
what you mean by the OO paradigm? i.e. data members are always
accessed through functions?
rmartin> Will everyone agree that it is a pure OOPL?
This is a different question, and let me say a pointless
one. Conformity is not such a useful concept, in the "real word" or in
computer science...
And yet we argue endlessly about purity, hybridity, etc. These
arguments are really about conformity: i.e. "Your way isn't pure
because you don't do it the way I do it...."
--
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.
Ulf Schuenemann
In article <4at0l3$b...@news4.digex.net>, e...@access4.digex.net (Ell) writes:
[..]
|> From what I understand, procedural means specifying "how" a task is done
|> rather than simply "what" is to be done. Some languages like ML, from
|> what I know of it, say I want "xyz" done, but don't specify how "xyz" is
|> done.
AFAIK what you describe is rather the difference between algorithmic ("how")
and declarative ("what").
IMO it depends on the point of view, whether functional
fun ack 0 n = n+1
| ack m 0 = ack m-1 1
| ack m n = ack m-1 ack m n-1;
tells you "what" without telling you "how". Purely procedural
PROCEDURE ack (IN m, IN n, OUT res) :
VAR tmp;
BEGIN IF m==0 THEN res := n+1;
ELIF n==0 THEN ack(m-1,1,res);
ELSE ack(m,n-1,tmp);
ack(m-1,tmp,res);
ENDIF;
END;
tells _me_ no more "how" than the ML-version does.
Only in a logic programm I see less "how" (ie more declarative):
ack(0,n,n+1).
ack(m,0,res) :- ack(m-1,1,res).
ack(m,n,res) :- ack(m,n,tmp),
ack(m-1,tmp,res).
[Here arithmetic arguments need to be evaluated before unifying.]
Ulf Schuenemann
Piercarlo Grandi
rmartin> In article <vwjenu7...@osfb.aber.ac.uk> p...@aber.ac.uk
rmartin> (Piercarlo Grandi) writes:
rmartin> Some will claim that C++ is not pure because it is a "hybrid"
rmartin> language (whatever that means).
jacob.gore> It means that it is possible to have data entities that are
jacob.gore> not objects: entities which are not encapsulated and are
jacob.gore> thus very vulnerable to types of changes that were not
jacob.gore> intended by their designer.
pcg> Or, more generally, that it is an OO extension to a non OO
pcg> language.
rmartin> If that is the definition, that is fine. However that
rmartin> definition says nothing whatever about "purity"; or the worth
rmartin> of "hybridity" vs. "purity".
Not that was my goal... Just to report what my understanding is.
rmartin> By that definition, Obj-C is hybrid (which many obj-C people
rmartin> will be very upset to learn.)
But it is a point made by Cox himself! He even claims, with much the
same arguments used by the C++ fans, that such hybridization is actually
an advantage from a _practical_ point of view.
rmartin> There are no good definitions for either "pure OOPL" or "hybrid
rmartin> OOPL". There is no consensus as to the definitions of either.
rmartin> (as this thread, and many many others have borne out through
rmartin> the last few years.)
rmartin> What *is* purity?
pcg> To me it is the strict and universal support and enforcement of
pcg> the OO paradigm. As I have argued in the years past, this is not
pcg> desirable, even if it is probably attainable, with some
pcg> limitations.
rmartin> That is a fine definition. But not one that is universally
rmartin> agreed upon. Moreover, it says nothing about whether such a
rmartin> language is possible.
Ah, of course -- indeed I wrote "To me" and "probably" and "with some
limitations". Also, as it is clear from my point below, I don't think
that a _universally_ agreed upon definition is even desirable.
rmartin> For example, how does one "enforce" the OO paradigm? Just what
rmartin> *is* the OO paradigm? If you say the OO paradigm is a paradigm
rmartin> in which everything is an object, [ ... ]
No, sorry for the misunderstanding: I was using the occasionally popular
definition, reported e.g. in OOSC by Meyer, according to which it is the
rule "decompose programs in modules such that all and only procedures
that access the representation of a type in the same module as the
definition of the type" (even he words it a bit differently).
rmartin> Which pure OOPL?
pcg> As far as I know, none exists: there are some language that have
pcg> something near to strict and universal support of the OO paradigm,
pcg> but very few have reasonably complete support for its enforcement
pcg> (while many will ensure no procedure outside a module accesses the
pcg> representation of the type encapsulated by the module, none that I
pcg> know requires all procedures inside that module to access that
pcg> representation).
rmartin> Is this what "enforcement" means? Methods of a class must
rmartin> access its own members through accessor methods? If so, does
rmartin> this also define what you mean by the OO paradigm? i.e. data
rmartin> members are always accessed through functions?
No, sorry for the not being clear. Enforcement means, among other
things, that all procedures in a class do in fact access the
representation of the type encapsulated in it, in other words that in:
class complex {
float re,im;
public:
const char *greeting() { return "hello world"; }
...
}
'greeting' is rejected as not belonging to 'complex'. Most OOPLs do
check that only the procedures in a class *can* access the
representation, but they don't check whether they *do* access it.
Note: I do regard 're' and 'im' above as procedures too, BTW, so that
class complex {
public:
float re,im;
...
}
would not violate the OO paradigm either. 're' and 'im' are compiler
generator destructor (not in the C++ sense!) functions, and making them
user visible may well make sense, and indeed just something of a
shorthand for something like:
class complex {
float _re,_im;
public:
inline float &re() { return &_re; }
inline float &im() { return &_im; }
...
}
rmartin> Will everyone agree that it is a pure OOPL?
pcg> This is a different question, and let me say a pointless
pcg> one. Conformity is not such a useful concept, in the "real word"
pcg> or in computer science...
rmartin> And yet we argue endlessly about purity, hybridity, etc. These
rmartin> arguments are really about conformity: i.e. "Your way isn't
rmartin> pure because you don't do it the way I do it...."
Good fun :-). More seriously: OO as we all know is a marketing
buzzword...
Matthew B. Kennel
: > 3) Because memory is a global resource, failure to manage it
: > properly can cause any part of the program to fail
: > unpredicatably. Calling a simple function or object method that
: > frees some piece of memory twice can cause an unpredicable
: > failure hours later in some completely unrelated and thoroughly
: > debugged part of the system that happens to get stuck with a
: > doubly allocated piece of memory. Yes, memory error checking
: > tools can reduce the possibility, but the possibility remains.
: Disagree. There is no requirement that "memory" (from the view of the
: langauge or programmer model) be a global resource. Further, there is
: no requirement that it be a "monolithic" resource (which is what you
: were probably really trying to get at). Separate classes can have
: there own memory pools and this can be tightly controlled via the type
: model. Sure, _typically_ this (global and monolithic) is how it is
: viewed and used.
This works only if only elements of the class are allowed to hold
onto references to objects of that class. If you want other people
to be able to use them (the whole point of an OO library) then
the question of
"Who has live references to this object?"
requires global knowledge.
Ulf Schuenemann
I support the view that AMM/GC is a very usefull tool
as it frees us from the burden of manual MM.
This helps to concentrate on applying the techniques of the
used paradigm (functional, procedural, relational, oo etc)
to find a solution for the given problem.
But AMM is not realy necessary for programs as MM
has no semantic effect on the language level
- it is basically an runtime-environment isssue.
IMHO AMM should not be a necessary requirement for the
general idea of object-orientation as there are cases
where AMM in the usual sense (GC) would do the wrong thing.
The key problem is that objects are _not_ just a peace of memory.
(a) Objects can be the abstraction of some process:
The existence of active objects in an endless loop makes a
semantic difference as long as they produce side effects.
Even it is not referenced by someone else the object can
have a usefull purpose. But GC would deallocate it in this
case, thus maybe violating the desired behavior of the program.
By what critieria can a AMM figure out that such an object may be
deallocated without violating the intended behavior of the program?
The only way I see is that the object _explicitly_ decides that
it can be deallocated now (provided that it is no longer referenced
by someone else). But then MM is not fully automatic any more.
(b) Objects can be the abstraction of some communication:
Before a cache-object is to be deallocated it has to flush.
Before a proxy-object is to be deallocated it might need to
formally close the connection to the server object.
GC doesn't care about such requirements.
A way out would be a special destructer-method that the AMM
calls before deallocating the object. But what if the destructor
stores a reference to self-object into some other object?
This makes the clear concept of GC more and more complicated.
Ulf Schuenemann
--------------------------------------------------------------------
,_. Ulf Schünemann
#, \ Fakultät für Informatik, Technische Universität München, Germany.
| > email: schu...@informatik.tu-muenchen.de
v=-< WWW: http://hphalle2.informatik.tu-muenchen.de/~schuenem/
Erik Ernst
In article <4bcc7b$m...@sunsystem5.informatik.tu-muenchen.de>
schu...@informatik.tu-muenchen.de (Ulf Schuenemann) writes:
[..]
I support the view that AMM/GC is a very usefull tool
as it frees us from the burden of manual MM.
This helps to concentrate on applying the techniques of the
used paradigm (functional, procedural, relational, oo etc)
to find a solution for the given problem.
Agreed, heartily!
But AMM is not realy necessary for programs as MM
has no semantic effect on the language level
- it is basically an runtime-environment isssue.
But "delete p;" certainly does have a semantic effect! On the other
hand: We want to program as-if memory resources were infinite,
i.e. we want to achieve the situation where MM is just allocation, and
deallocation happens in an automatic and safe manner, just as if it
didn't happen at all!
IMHO AMM should not be a necessary requirement for the
general idea of object-orientation as there are cases
where AMM in the usual sense (GC) would do the wrong thing.
The key problem is that objects are _not_ just a peace of memory.
(a) Objects can be the abstraction of some process:
The existence of active objects in an endless loop makes a
semantic difference as long as they produce side effects.
Even it is not referenced by someone else the object can
have a usefull purpose. But GC would deallocate it in this
case, thus maybe violating the desired behavior of the program.
By what critieria can a AMM figure out that such an object may be
deallocated without violating the intended behavior of the program?
I don't think this is a problem: An active object (e.g. a component in
BETA, or some coupling of a thread mechanism and an object in
C++/Eiffel/CLOS/..) is known by (referred-to by) some kind of
scheduler, and it is purely an implementation detail to ensure that
the garbage collector knows all live (autonomous) objects. As long as
it is running *or* some root object has a reference-path to it, it
cannot die.
The only way I see is that the object _explicitly_ decides that
it can be deallocated now (provided that it is no longer referenced
by someone else). But then MM is not fully automatic any more.
Finalization (e.g. closing a file descriptor when nobody uses it
anymore, by linking this to the destruction/deallocation of some
object) is sometimes very useful. IMHO this is just a broadening of
AMM into something which could be called ARM (Automatic Resource
Management, that is ;-).
(b) Objects can be the abstraction of some communication:
Before a cache-object is to be deallocated it has to flush.
Before a proxy-object is to be deallocated it might need to
formally close the connection to the server object.
GC doesn't care about such requirements.
I think of these things as other examples of ARM. Of course,
it can be quite tricky to implement correctly. Each new kind of
resource to manage may impose the need for a new kind of decision
procedure: when/how to free this resource? Still, I think the
ultimate goal will be ARM, as far as possible.
A way out would be a special destructer-method that the AMM
calls before deallocating the object. But what if the destructor
stores a reference to self-object into some other object?
This makes the clear concept of GC more and more complicated.
Yes! (For this particular problem it's possible to put the finalized
object aside, collecting it at next GC---if the object is indeed dead
by then). But also: What if different finalizations depend on each
other? (The database operations must be comitted _before_ the TCP/IP
connection to the database is closed). What if a resource is not
discovered in a timely manner? ("too many file descriptors", because
the collector didn't close them soon enough).. etc. etc.
Indeed I think that this considerable complexity _calls for_ general
solutions. It is not going to get easier or safer to reinvent this
wheel for each new application. Actually it's a question of reusing a
general solution instead of rewriting a special case of many times.
Sounds quite OO, right?
If it works out like memory management, it just might be more
efficient, too ;-)
regards,
--
Erik Ernst eer...@daimi.aau.dk
Computer Science Department of Aarhus University, Denmark
Piercarlo Grandi
>>> Schuenemann) said:
schuenem> I support the view that AMM/GC is a very usefull tool
schuenem> as it frees us from the burden of manual MM.
schuenem> This helps to concentrate on applying the techniques of the
schuenem> used paradigm (functional, procedural, relational, oo etc)
schuenem> to find a solution for the given problem.
Well, yes, well put.
schuenem> But AMM is not realy necessary for programs as MM
schuenem> has no semantic effect on the language level
schuenem> - it is basically an runtime-environment isssue.
It can be argued both ways, but on a strict reading this is correct.
schuenem> [ ... ] The key problem is that objects are _not_ just a peace
schuenem> of memory.
Adn indeed this is why it can have some semantic effect, in a loose
reading of your statement above...
schuenem> (a) Objects can be the abstraction of some process: [ ... ]
Now that you mention this, there is a paper by Hewitt about the garbage
collection of processes. This is an interesting topic in the actor model
he proposes: if one has actors (active object) then one organizes
programs as mobs of actors, and it might pay off to have some of them
perform greedy computation, that is computing towards some result that
_might_ be needed. The problem then is that if that results turns out
not to be needed, one is wasting process(or)s. He suggests a garbage
collection of processes that sweeps the set of actors and kills those
that are computing results that won't be needed.
The idea nowadays sounds strange, because it is predicated on the
assumption that one has lots and lots of relatively low power
processors, while the industry (save for some highly specialized
exceptions) has instead gone down the path of ever more powerful single
processors, but perhaps it will find favour again if/when the ever more
powerful uniprocessor path yields diminishing returns.
Jon S Anthony
Actually, what you say here is only the case if you assume the "standard"
global monolithic GC style of AMM. So you've stated a tautology. And??
Ulf Schuenemann
In article <yz8spid...@fraxinus.daimi.aau.dk>,
|> In article <4bcc7b$m...@sunsystem5.informatik.tu-muenchen.de>
|> schu...@informatik.tu-muenchen.de (Ulf Schuenemann) writes:
[..]
|> solutions. It is not going to get easier or safer to reinvent this
|> wheel for each new application. Actually it's a question of reusing a
|> general solution instead of rewriting a special case of many times.
|> Sounds quite OO, right?
Yes, a general solution. Wanna try to work that out a bit?
|> (a) Objects can be the abstraction of some process:
[..]
|> By what critieria can a AMM figure out that such an object may be
|> deallocated without violating the intended behavior of the program?
|>
|> I don't think this is a problem: An active object (e.g. a component in
|> BETA, or some coupling of a thread mechanism and an object in
|> C++/Eiffel/CLOS/..) is known by (referred-to by) some kind of
|> scheduler, and it is purely an implementation detail to ensure that
|> the garbage collector knows all live (autonomous) objects. As long as
|> it is running *or* some root object has a reference-path to it, it
|> cannot die.
So the only way that an autonomous objects A can die, is that it tells
the scheduler: I'm done now, stop scheduling me.
(I would prefere scheduler != AMM, to keep each of them simple.)
Then, in this scenario the schedular throws away the reference to A,
so that AMM can kill it.
If there is still another reference to A, then A can be activated
from this place like any other (non-autonomous) object can.
Then A could decide to contact the schedular to get scheduled again...
That sounds fine. I see autonomous objects are no obstacle to AMM.
[..]
|> But also: What if different finalizations depend on each
|> other? (The database operations must be comitted _before_ the TCP/IP
|> connection to the database is closed).
Mmmmh. How about a special kind of reference from the TCP/IP-connection
to the database-operation-object, meaning "this object has to get killed,
before I may be killed"? Of course this reference can not be used to
send messages to an object, as the referenced object may already be dead.
This way one could construct an acyclic(!) graph of finalized-before-relations
that the AMM has to consider.
|> What if a resource is not
|> discovered in a timely manner? ("too many file descriptors", because
|> the collector didn't close them soon enough).. etc. etc.
... has someone any ideas?
R. Kerr
> >>> On 21 Dec 1995 19:23:23 GMT, schu...@informatik.tu-muenchen.de (Ulf
> >>> Schuenemann) said:
> schuenem> But AMM is not realy necessary for programs as MM
> schuenem> has no semantic effect on the language level
> schuenem> - it is basically an runtime-environment isssue.
> It can be argued both ways, but on a strict reading this is correct.
This is most certainly NOT correct. Absence of AMM forces the inclusion in
the application logic level of mechanisms which have nothing to do with
the logic of the application. Apart from the additional complexity this
implies, it may also inhibit how one might prefer to structure the system.
If that is not a semantic effect I don't know what is, and it is contrary
to the considerations from which OO developed.
This is a constantly recurring theme which is showing very little sign of
reaching a concensus. However, I cannot help wondering what proportion
those arguing against the need for AMM have actually experienced its
benefits in complex situations, and what proportion of those exposed to AMM
ever argue against it.
Cheers....Ron
Piercarlo Grandi
R.Kerr> Piercarlo Grandi (pier...@sabi.demon.co.uk) wrote:
>>>>>>> On 21 Dec 1995 19:23:23 GMT, schu...@informatik.tu-muenchen.de
>>>>>>> (Ulf Schuenemann) said:
schuenem> But AMM is not realy necessary for programs as MM has no
schuenem> semantic effect on the language level - it is basically an
schuenem> runtime-environment isssue.
Indeed, let me add, memory reclamation, whether automatic or manual, is
entirely a runtime-environment issue: adding memory reclamation can only
introduce bugs in a program, and indeed it is done for purely pragmatic
reasons (address space, or working set, not being allowed to grow
indefinitely).
piercarl> It can be argued both ways, but on a strict reading this is
piercarl> correct.
R.Kerr> This is most certainly NOT correct. Absence of AMM forces the
R.Kerr> inclusion in the application logic level of mechanisms which
R.Kerr> have nothing to do with the logic of the application. Apart from
R.Kerr> the additional complexity this implies, it may also inhibit how
R.Kerr> one might prefer to structure the system.
Well, the way the runtime environment is shaped often, and not just for
AMM, does have a profound effect on program pragmatics and structure in
most cases; for example program structure and logic is often deeply
influenced, down to the choice of particular data structures and
algorithms by whether the program is expected to run under virtual
memory (and even by the type of VM replacement policy expected!) or not.
Yet this, on a strict reading, has not semantics effect at the language
level, it is strictly a runtime-environment issue.
R.Kerr> If that is not a semantic effect I don't know what is,
Yes, I agree.
It is a semantic effect, but one on the level of pragmatics, of the
runtime-environment, not at the language level, strictly speaking.
As I understand Ulf, he was arguing as to the nature/level of the
semantic effect, not that it does not exist; even if this too could be
argued both ways (depending on one wants to make a strict separation
between pragmatics and semantics or not).
R.Kerr> and it is contrary to the considerations from which OO
R.Kerr> developed.
Well, to me OO developed as a technology to achieve high security
modular systems, and then incidentally found expression at the language
level too a dozen years later. As to this AMM is basically an orthogonal
issue.
On the other hand the reasons for which people _use_ (as opposed have
researched into) OO, namely seeking better returns from sw investments,
do imply that AMM (reclamation) is an important, usually essential,
runtime-environment technology, as it pushes yet another non
application-specific detail into a reusable standard library.
R. Kerr
> Well, to me OO developed as a technology to achieve high security
> modular systems, and then incidentally found expression at the language
> level too a dozen years later. As to this AMM is basically an orthogonal
> issue.
OO originates from considering how to master complexity in systems. It
hinged on factorising system design through encapsulation of related
issues - and, as a corollary, the separation of unrelated issues. Probably
all the characteristics embraced by the "modern" view of OO stem from, or
are by-products of, this, although many have lost sight of the real nature
of the original inspiration, if indeed they ever knew.
Many who indulge in the often religious arguments about the true nature
of OO would do well to read the historical accounts of the development of
SIMULA, these giving clear insights into how and why the fundamental
concepts were identified and developed.
Cheers....Ron
Piercarlo Grandi
R.Kerr> Many who indulge in the often religious arguments about the true
R.Kerr> nature of OO would do well to read the historical accounts of
R.Kerr> the development of SIMULA, these giving clear insights into how
R.Kerr> and why the fundamental concepts were identified and developed.
I cannot agree more! This is actually one of my pet peeves -- I have
been posting excerpts from Simula-67 publications for several years in
'comp.object', to illustrate the (historical) fundamentals and where
certain mistakes of mistakes have originated and why (prefixing,
mainly).
Too bad relatively few people have bothered to dig out those ancient
materials (I still have a copy of one of the first editions of the
Common Base definition). But, interestingly, there is a freeware
compiler for Simula(-67) under Linux:
Begin3
Title: Cim -- Simula Compiler based on the C programming language
Version: cim-1.56
Entered-date: 15.02.95
Description: A Compiler for the programming language SIMULA.
Keywords: Cim, Simula, Simulation
Author: Sverre Hvammen Johansen, Terje Mjoes, and Stein Krogdahl.
(email: c...@ifi.uio.no).
Maintained-by: Sverre Hvammen Johansen (email: c...@ifi.uio.no)
Primary-site: sunsite.unc.edu /pub/Linux/devel/simula
300kB cim-1.56.gz
Alternate-site: ftp.ifi.uio.no /pub/cim/
Original-site: ftp.ifi.uio.no /pub/cim/
Platforms: Linux, but should work on any Unix box with a C compiler.
Copying-policy: GPL
End
(actually the most recent verison I have is 1.64, not 1.56, there might
be more recent ones).
With the compiler distribution there is an article with some history of
how first SIMULA-I and then Simula-67 came into existence.
Let me add that those that think that OO concepts and technology were
born with Simula-67 might benefit from reading Levy's book on capability
systems (Digital Press).
It is still little known, but OO technology was "old" (half a dozen
years at least) when Simula-67 appeared; however the latter was the
first case in which _some_ of the concepts could be expressed directly
at the linguistic level (instead of just at the OS or architecture level
as before). Unfortunately this has led many to identify OO technology
with OO languages, and their features...
Let me repeat here what you wrote of OO some weeks ago:
> I have been in this area for longer than almost anyone else in the
> world. That doesn't make me a supreme expert but I have had much
> longer than most to mull things over. Moreover, I have seen this
> topic go backwards while most others think they have seen it go
> forwards. That gives for different perspectives.
R. Kerr
> I cannot agree more! This is actually one of my pet peeves -- I have
> been posting excerpts from Simula-67 publications for several years in
> 'comp.object', to illustrate the (historical) fundamentals and where
> certain mistakes of mistakes have originated and why (prefixing,
> mainly).
> Too bad relatively few people have bothered to dig out those ancient
> materials (I still have a copy of one of the first editions of the
> Common Base definition).
The following could be quite illuminating:
"The Development of the SIMULA Languages", K. Nygaard & O-J-Dahl,
in "History of Programming Languages" (ed. Wexelblat), Academic
Press, New York, 1981.
"Compiling SIMULA: A Historical Study of Technological Genesis",
Jan Rune Holmevik, IEEE Annals of the History of Computing,
vol.16, no. 4, 1994.
These papers together give an all-round account of the conception,
gestation and birth pangs of the OO paradigm.
The SIMULA Common Base Definition survives in the form of the Swedish
(SIMULA is, itself, Norwegian) SIMULA Standard SS 63 61 14 (ISBN
91-7162-234-9). This publication is expensive, but there may just be a
copy in your library. In the 1980s, considerable effort was devoted to
attempting to establish an ISO standard for SIMULA. This was thwarted by
the fact that the representatives of insufficient countries felt this
important enough to adopt even as a "work item" in the standardisation
process. The Swedish National standard was all that could be accomplished
before money and energy were exhausted.
But, interestingly, there is a freeware
> compiler for Simula(-67) under Linux:
... and a number of commercial implementations for popular modern
platforms. It is interesting to observe that despite the fact that the
vast majority of the computing profession are unaware of SIMULA, after
almost 30 years it still survives as a modern practical work horse and in
a form not fundamentally different from its original design - a measure of
inherent and enduring quality surely.
> Let me add that those that think that OO concepts and technology were
> born with Simula-67 might benefit from reading Levy's book on capability
> systems (Digital Press).
> It is still little known, but OO technology was "old" (half a dozen
> years at least) when Simula-67 appeared; however the latter was the
> first case in which _some_ of the concepts could be expressed directly
> at the linguistic level (instead of just at the OS or architecture level
> as before). Unfortunately this has led many to identify OO technology
> with OO languages, and their features...
There are always points in the history of technological development when
threads of innovation from several sources coalesce and crystalise to form
a new concept with its own identity, and SIMULA/OO is no exception.
SIMULA drew on quite a few sources. However there was also a large measure
of original thought, as described in the first of the references above.
Cheers....Ron