Re: pointers & OOP

[John Robinson <john@jr-and-assoc.demon.co.uk>]

In article <7gn7gr$fr5$1@nnrp1.dejanews.com>, Robert Dewar
<robert_dewar@my-dejanews.com> writes
>In article <$DL10CAsSgL3Iwj3@jr-and-assoc.demon.co.uk>,
>  John Robinson <chat@jr-and-assoc.demon.co.uk> wrote:
>
>> I still stand by the assertion that to do a full OO application you will
>> need to use pointers (smart or otherwise) somewhere along the line.
>> Yes, you can hide the implementation detail (and you should) but you
>> will still need them.
>
>You can assert anything, and you can stand by it, but that does not make
>it so. 

I am expressing an opinion.  Reality only exists in the eye of the
observer, therefore in my eyes I am right (I was wrong once before - it
was a Wednesday :-) );

>Please give some idea of why you think this. It seems plainly obvious
>to me that you can do full object oriented programming without pointers, and
>indeed I find pointers and OO to be pretty much orthogonal concepts, and so
>it is not surprising that they are orthogonal language features.
>
>Yes, closures need pointers, but we don't need closures for many kinds of
>OO programming!

I have yet to build an OO system which didn't use some kind of
collection class - if you have a collection class you have to use
pointers. 

Am I missing something here?  Has anyone yet suggested a way of building
a collection class which does not use pointers?

Also, on the GNAT list Robert said:

>encapsulation per se is not considered an OOP language feature, but in
>anyc ase this entire thread should move to CLA, it has nothint to do 
>with GNAT.

I consider encapsulation to be central to the concept of an object.
Without encapsulation you are not using objects and are not even
attempting to gain the prime benefits which are claimed for the
approach.  

Hence, a mapping from UML to Ada 95 should always map a single UML class
box onto a package containing a single tagged type.  Although the
language allows multiple tagged types to be declared in a single package
it makes no sense whatsoever to do so.  

In fact, I believe that this illustrates the reason why this thread has
generated so much discussion.  One can take a narrow view, in which one
examines the language features which can be used to support an OO style
of design/coding.  Alternatively one can take a wider view, in which the
concepts central to OO drive the way in which you use a language.
-- 
John Robinson
John Robinson & Associates
www.jr-and-assoc.demon.co.uk