pointers & OOP

pointers & OOP

[Tom Moran]

In GNAT chat, John Robinson said:
> It is difficult to do anything really useful with Ada 95 OOP features
> without the use of pointers.
Robert Dewar pointed to finalization actions as just one example
of using OOP without pointers, and Matthew Heaney said:
> ... it would be helpful to have a list of typical examples.
so here's another:
  Sometimes, perhaps for task-safety or resource ownership
reasons, the task that wants something done can't do it, but
needs to ask a different service task to do the job.  Rather
than have a proliferation of 'entry's in the service task, one
per type of job, make a single service entry that takes a
"Job:in out Job_To_Do'Class" parameter and whose 'accept' merely
calls a "Do_It(Job)" procedure.  Any time some new type of job
needs to be done, simply declare a child of Job_To_Do, with
appropriate places in the record extension for parameters, and
overide procedure Do_It(Job : in out Job_To_Do).  Then a call
to the service entry will dispatch to the desired Do_It routine
so the service task will actually be the one executing the Do_It
code.  Essentially you are using Job_To_Do's dispatch table to
pass a procedure pointer, and using the record extension to
hold the parameters, but you are getting the compiler to build,
and check, everything instead of relying on screwup-able
explicit pointers.

pointers & OOP

[Matthew Heaney]

John Robinson <john@jr-and-assoc.demon.co.uk> writes:

> It is difficult to do anything really useful with Ada 95 OOP features
> without the use of pointers.

No.  For example, a factory method in Ada95 returns an object by-value:

  procedure Print (Stack : in Root_Stack'Class) is
  
    Iterator : Root_Iterator'Class := Get_Iterator (Stack);

  begin

    while not Is_Done (Iterator) loop

      Put (Get_Item (Iterator));

      Advance (Iterator);

    end loop;

  end Print;


Function Get_Iterator is a (dispatching) factory method that returns an
object whose type is class-wide.  The iterator object goes in the stack.
No heap is used.  Is_Done, Get_Item, Advance, are all dispatching
operations.

This is an example of what Jean-Pierre was talking about.  No heap, no
pointer.

> Any collection class for example will need to use pointers, even if
> the collection is based around a fixed length array.  

Yes, a collection whose items have a class-wide type will require
pointer use.  But you can use a smart pointer, so you don't have to
worry about any pointer manipulation headaches.  Gives you the same as a
reference in other OO languages.


> Having said that, Ada still provides a more predictable OO environment
> with better compile time checking than other OO languages (that should
> get the Java crowd going :-)).

I don't think they'd disagree that Ada95 has better compile time
checking.  The argument is, How important is compile-time checking to
the programmer?  

Most programmers are oblivious to the benefits of rigorous compile-time
checking, and many programmers actually like having bugs (because they
get to find them and fix them), so "Ada95 has better checking" is a
tough sell.

For some ideas on smart pointers, how to control instance creation, etc,
peruse the articles (mostly Oct/Nov 98 to the present) in the Ada95
design patterns archive at the ACM.

<http://www.acm.org/archives/patterns.html>

Matt

Re: pointers & OOP

[Matthew Heaney]

Matthew Heaney <matthew_heaney@acm.org> writes:

> John Robinson <john@jr-and-assoc.demon.co.uk> writes:
> 
> > Any collection class for example will need to use pointers, even if
> > the collection is based around a fixed length array.  
> 
> Yes, a collection whose items have a class-wide type will require
> pointer use.  But you can use a smart pointer, so you don't have to
> worry about any pointer manipulation headaches.  Gives you the same as a
> reference in other OO languages.

I should also have mentioned that when you declare the primitive
operations of the type to take access parameters, this effectively hides
the fact that you manipulating a pointer.  The syntax of method
invokation is the same as for a non-pointer.


> For some ideas on smart pointers, how to control instance creation, etc,
> peruse the articles (mostly Oct/Nov 98 to the present) in the Ada95
> design patterns archive at the ACM.
> 
> <http://www.acm.org/archives/patterns.html>

The ACM patterns archives also has lots of examples of the access
parameter technique.

Matt

Re: pointers & OOP

[John Robinson]

In article <m3k8uszln5.fsf@mheaney.ni.net>, Matthew Heaney
<matthew_heaney@acm.org> writes
>John Robinson <john@jr-and-assoc.demon.co.uk> writes:
>
>> It is difficult to do anything really useful with Ada 95 OOP features
>> without the use of pointers.
>
<snip>
>
>> Any collection class for example will need to use pointers, even if
>> the collection is based around a fixed length array.  
>
>Yes, a collection whose items have a class-wide type will require
>pointer use.  But you can use a smart pointer, so you don't have to
>worry about any pointer manipulation headaches.  Gives you the same as a
>reference in other OO languages.
>

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.

I accept that one can also gain an advantage in many areas by using the
OOP features to do individual jobs (such as the use of controlled types
which Robert used as an example).  I also accept that some parts of a
system may be able to avoid pointers where other languages would need
them (such as the factory method which you described).

<snip>

>
>I don't think they'd disagree that Ada95 has better compile time
>checking.  The argument is, How important is compile-time checking to
>the programmer?  
>
>Most programmers are oblivious to the benefits of rigorous compile-time
>checking, and many programmers actually like having bugs (because they
>get to find them and fix them), so "Ada95 has better checking" is a
>tough sell.

I agree.  The software profession will only become a profession when
programmers accept that they have a job to do and are not paid to have
"fun" whilst "playing" with their bugs!


-- 
John Robinson
John Robinson & Associates
www.jr-and-assoc.demon.co.uk

Re: pointers & OOP

[Samuel Mize]

John Robinson <chat@jr-and-assoc.demon.co.uk> wrote:
> In article <m3k8uszln5.fsf@mheaney.ni.net>, Matthew Heaney
> <matthew_heaney@acm.org> writes
>>John Robinson <john@jr-and-assoc.demon.co.uk> writes:
>>
>>> It is difficult to do anything really useful with Ada 95 OOP features
>>> without the use of pointers.

Or to do anything with any data type whose size may wildly vary, if
you want to use it as a building-block for more sophisticated data
structures.  This isn't OO-specific, although it's certainly true
of OO.  For instance, you can't have an array of "string."  You have
to have an array of access-to-string.

I didn't see the original message, just some replies.  Was there a
more-significant statement this was intended to show or support?

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: pointers & OOP

[Martin C. Carlisle]

In article <7gl43b$2481@news2.newsguy.com>,
Samuel Mize  <smize@imagin.net> wrote:
>John Robinson <chat@jr-and-assoc.demon.co.uk> wrote:
>>>> It is difficult to do anything really useful with Ada 95 OOP features
>>>> without the use of pointers.
>
>I didn't see the original message, just some replies.  Was there a
>more-significant statement this was intended to show or support?

A very good question, as in Java, e.g., you can't do anything without
heap allocated objects (although the fact you are using pointers is a bit
more obscured).  I almost always use pointers with my tagged records, simply
because it is impossible to have an array of non-homogenous objects.

--Martin

-- 
Martin C. Carlisle, Asst Prof of Computer Science, US Air Force Academy
carlislem@acm.org, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standards or 
policy of the US Air Force Academy or the United States Government.

Re: pointers & OOP

[Robert Dewar]

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. 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!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: pointers & OOP

[Robert Dewar]

In article <7gl43b$2481@news2.newsguy.com>,
  Samuel Mize <smize@imagin.net> wrote:
> For instance, you can't have an array of "string."  You have
> to have an array of access-to-string.

But you can have an array of bounded strings, and that may be
fine for many applications, and more than fine for an application
that wants to use an OO approach but is prevented from using any
heap allocation. The Ada 95 OO features are carefully designed to
permit such an approach.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: pointers & OOP

[Mike Silva]

Robert Dewar wrote in message <7gn7gr$fr5$1@nnrp1.dejanews.com>...

>>Yes, closures need pointers, but we don't need closures for many kinds
>>of OO programming!

I'm going to demonstrate my ignorance here (but it gets easier the more I do
it...).  I've seen the term "closures" mentioned often in the context of
programming / languages, but I don't know what it means (I started life as a
hardware engineer...).  Anybody have an answer, or a direction to look?
Thanks.

Mike

Re: pointers & OOP

[John Robinson]

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

Re: pointers & OOP

[Robert Dewar]

In article <MVsZ8DAT0AM3EwF3@jr-and-assoc.demon.co.uk>,
  John Robinson <john@jr-and-assoc.demon.co.uk> wrote:

> 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.

Well of course the notions of encapsulation and data abstraction
are central to object oriented programming, as are many other
concepts such as subprograms.

But this does not make them part of OOP features in a language.
Data abstraction ane encapsulation features have been in all modern
programming languages for a long time, quite independently from the
more recent enthusiasm for object oriented programming.

Far too many programmers have recently discovered encapsulation and
data abstraction, and think that they are consequently doing object
oriented programming.

That is why I will repeat, I do not consider encapsulation features
per se to be part of the OOP features of a modern programming language.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: pointers & OOP

[Matthew Heaney]

John Robinson <john@jr-and-assoc.demon.co.uk> writes:

> 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.  

This is completely wrong.  Browse the ACM Ada95 patterns archive for
many examples.

<http://www.acm.org/archives/patterns.html>

Re: pointers & OOP

[Robert Dewar]

In article <MVsZ8DAT0AM3EwF3@jr-and-assoc.demon.co.uk>,
  John Robinson <john@jr-and-assoc.demon.co.uk> wrote:

> 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.

This is very wrong. In fact I would say that you have essentially completely
missed one of the most powerful features of Ada, namely that the packages
and tagged types need NOT be in 1-1 correspondence. You sound like a C++
programmer trying to squeeze the paradigms you are used to into Ada 95 in
an ugly and very unnatural way. I think you should look at a bunch of Ada
code to get the feeling for why the above recommendation is not just wrong,
but very wrong!

Very often putting multiple types into a single package solves in a neat and
clean way nasty problems that simply don't have neat solutions in other
languages.

You are tieing BOTH hands behind your back if you adopt this completely
unnecessary and damaging restriction.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: pointers & OOP

[John Robinson]

In article <7gq27t$vnd$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-
dejanews.com> writes
>In article <MVsZ8DAT0AM3EwF3@jr-and-assoc.demon.co.uk>,
>  John Robinson <john@jr-and-assoc.demon.co.uk> wrote:
>
>> 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.
>
>This is very wrong. In fact I would say that you have essentially completely
>missed one of the most powerful features of Ada, namely that the packages
>and tagged types need NOT be in 1-1 correspondence. 

No I didn't miss this fact.  I choose to implement a one-to-one mapping,
and judging by a quick review of my bookshelf I am in good company.

>You sound like a C++
>programmer trying to squeeze the paradigms you are used to into Ada 95 in
>an ugly and very unnatural way. 

Fancy being accused of being a C++ programmer, there is a first time for
everything :-)

>Very often putting multiple types into a single package solves in a neat and
>clean way nasty problems that simply don't have neat solutions in other
>languages.

Such as?  

The use (in general) of one "major" type per package goes back to my
earliest days with Ada 83, and is of course inherent in Booch's original
"Software Engineering with Ada" text which was so influential in the
adoption of ADT-based programming in the Ada world.  This approach,
which I have (so far) successfully carried over into Object Oriented Ada
95 code, brings a number of benefits (e.g. straightforward traceability
between analysis and code, very clear separation of concerns etc).

However, I am open to other approaches, if the benefits are clear.

>
>You are tieing BOTH hands behind your back if you adopt this completely
>unnecessary and damaging restriction.

I would be very interested in seeing a specific example of why this is
damaging.  Perhaps a specific reference to the patterns archive cited by
Mathew?

>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

-- 
John Robinson
John Robinson & Associates
www.jr-and-assoc.demon.co.uk

Re: pointers & OOP

[Francois Godme]

Robert Dewar wrote:

> 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. 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!
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

You can perfectly avoid pointers when you build new classes by aggregating
instances of concrete classes but are forced to use pointers with instances of
unknown concrete subclasses of known abstract classes.

For instance, let's say you want to design a set of widgets, you can abstract
the window class and provide two
concrete implementations of the window class, one for the Xlib, one for Win32.
The Widget class will have a window'class pointer as it tries to avoid to know
the exact details of the actual window.

Re: pointers & OOP

[Simon Wright]

John Robinson <john@jr-and-assoc.demon.co.uk> writes:

> 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.

It may make sense to have such a rule with regard to public
types. Indeed, you need some such translation rules between the UML
and the Ada or you are going to get lost (I suppose you could have a
'design' stage, where you map the UML onto the Ada using some other
formalism; I don't know enough about UML, perhaps it has this
technology inbuilt).

Perhaps there could be a set of patterns for recognising UML clusters
that should be translated into Ada using multiple-types-in-one-package.

However, I can see no need to restrict yourself with regard to private
types! of course, they are implementation support and so not likely to
appear in the UML anyway ..

I'm not holding out the Booch Components (well, anyway, the Ada95
version) as a stunning example of design, but consider the Graphs
package:

  generic
    [...]
  package BC.Graphs is

    [...]

    type Graph is abstract new Ada.Finalization.Limited_Controlled
       with private;
    type Graph_Ptr is access all Graph'Class;

    type Vertex is abstract new Ada.Finalization.Controlled with private;

    type Arc is abstract new Ada.Finalization.Controlled with private;

Clearly these three things are intimately intertwingled!

Re: pointers & OOP

[John Robinson]

In article <x7v7lqmu4is.fsf@pogner.moho>, Simon Wright
<simon@pogner.demon.co.uk> writes
>John Robinson <john@jr-and-assoc.demon.co.uk> writes:
>
>> 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.
>
>It may make sense to have such a rule with regard to public
>types. Indeed, you need some such translation rules between the UML
>and the Ada or you are going to get lost (I suppose you could have a
>'design' stage, where you map the UML onto the Ada using some other
>formalism; I don't know enough about UML, perhaps it has this
>technology inbuilt).

No I wouldn't say that any of this was "built in" to the UML but if you
consider that the primary public type represents the data-centered heart
of an object one can see that it acts as a hook onto which you may hang
behaviour.  Having two hooks inevitably means bringing more behaviour
into one class with the danger that you then confuse the role of the
class give too much responsibility to one class (resulting in increased
maintenance overhead on that class).

>
>Perhaps there could be a set of patterns for recognising UML clusters
>that should be translated into Ada using multiple-types-in-one-package.
>

Maybe, but it may be simpler to stick to a consistent mapping rule. 

>However, I can see no need to restrict yourself with regard to private
>types! of course, they are implementation support and so not likely to
>appear in the UML anyway ..
>

Agreed.  Similarly for "support" types, i.e. those built merely to
support the declaration and/or use of the main type.  In the Booch
component is the arc a support type or an entity in its own right? 
The key factor (for me - and I am sure that I will get shouted at for
saying this) is that if a type is associated with behaviour then this
behaviour should be physically implemented in a dedicated, cohesive
package.  
-- 
John Robinson
John Robinson & Associates
www.jr-and-assoc.demon.co.uk

Re: pointers & OOP

[Tom Moran]

Suppose you have
  type Root is abstract tagged ...
  procedure Very_General(X : in out Root);
private
  procedure Internal_Updating(X : in out Root'class);
and then Root has a son and a daughter
  type Son is new Root with ...
and 
  type Daughter is new Root with ...
and suppose that Son and Daughter need to use Root's Internal_Updating
procedure.  If they are both declared in the same package as Root, no
problem.  Even if they are declared in child packages of Root, no
problem.  But if they are declared in truly separate packages, then
either they cannot see Internal_Updating, or else you move
Internal_Updating to the public part of Root's package, thus letting
anybody see and call Internal_Updating.
   How would you propose structuring this if you are required to have
1-1 package/class?
  

Re: pointers & OOP

[John Robinson]

In article <3731d200.1993345@news.pacbell.net>, Tom Moran
<tmoran@bix.com> writes
>Suppose you have
>  type Root is abstract tagged ...
>  procedure Very_General(X : in out Root);
>private
>  procedure Internal_Updating(X : in out Root'class);
>and then Root has a son and a daughter
>  type Son is new Root with ...
>and 
>  type Daughter is new Root with ...
>and suppose that Son and Daughter need to use Root's Internal_Updating
>procedure.  If they are both declared in the same package as Root, no
>problem.  Even if they are declared in child packages of Root, no
>problem.  But if they are declared in truly separate packages, then
>either they cannot see Internal_Updating, or else you move
>Internal_Updating to the public part of Root's package, thus letting
>anybody see and call Internal_Updating.
>   How would you propose structuring this if you are required to have
>1-1 package/class?
>  

Use parent-child structuring.  Internal_Updating is a protected
operation.  I would still consider this to be a one to one mapping,
although I don't use parent-child packages unless I have to.

I would also mark the class diagram (probably with a stereotype) to
provide a visual clue that the parent-child relationship exists.

If there is a significant amount of behavioural coupling between the
classes they probably ought to be combined anyway (maybe you have split
one role across two classes?).
-- 
John Robinson
John Robinson & Associates
www.jr-and-assoc.demon.co.uk

Re: pointers & OOP

[Tom Moran]

>Use parent-child structuring.  Internal_Updating is a protected
>operation.  I would still consider this to be a one to one mapping,
>although I don't use parent-child packages unless I have to.
  If you'll allow child packages as "separate packages" it certainly
makes "1-1 packages/classes" a lot less draconian.  OTOH, suppose you
really wanted procedure Internal_Updating to be visible to Son and
Daughter but *absolutely not* to any other package masquerading as
Parent.Prodigal_Son.  Then you'd be forced to put Son and Daughter
inside the same package as Root (unless you went to a lot of trouble
with "doorman" routines).

Re: pointers & OOP

[Brian Rogoff]

On Wed, 5 May 1999, John Robinson wrote:

> In article <7gq27t$vnd$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-
> dejanews.com> writes
> >In article <MVsZ8DAT0AM3EwF3@jr-and-assoc.demon.co.uk>,
> >  John Robinson <john@jr-and-assoc.demon.co.uk> wrote:
> >
> >> 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.

OK, you agree with Bertrand Meyer that the class is the unit of modularity 
I happen to think otherwise. 

> >This is very wrong. In fact I would say that you have essentially completely
> >missed one of the most powerful features of Ada, namely that the packages
> >and tagged types need NOT be in 1-1 correspondence. 
> 
> No I didn't miss this fact.  I choose to implement a one-to-one mapping,
> and judging by a quick review of my bookshelf I am in good company.

My bookshelf says different.

> >You sound like a C++
> >programmer trying to squeeze the paradigms you are used to into Ada 95 in
> >an ugly and very unnatural way. 

I think we should stop accusing each other of being C or C++ programmers,
since many professional programmers have used C and C++, and could easily 
qualify. Besides, Ada 95 is the only language I know in which pointers 
and OOP are orthogonal, so I could just as easily accuse Mr. Robinson of 
being an Eiffel programmer trying to do a little paradigm squeezing :-).

> >Very often putting multiple types into a single package solves in a neat and
> >clean way nasty problems that simply don't have neat solutions in other
> >languages.
> 
> Such as?  

Providing access to representation information. A good example is an
iterator class or type. 

> The use (in general) of one "major" type per package goes back to my

Well, now its become one "major" type per package. This is a lot weaker
than your original claim. I might even agree with this one, and my own 
example clearly has the collection as the major type. A naming convention
which I like, which some people find too C-ish, is to name the major type
of a package "T" and the minor types things like Iterator_T or Index_T,
and rely on the package name to "really" name the major type, like
Lists.T, Lists.Iterator_T, etc. I still wouldn't reject a package with two 
symmetric (neither more major than the other), coencapsulated tagged types
as being a bad design, I just can't remember having had to do that except 
when using access discriminants to do MI, which doesn't really count.

I think your original claim about the inability to do OOP without pointers 
is more convincing in the weak version too, since there are some things 
like heterogeneous collections (in general) and access discriminant tricks 
(in Ada 95) that require access types, but its obvious that you can use 
OOP features in a pointerless program. How much OOP do you have to use for
an application to be a major OOP application?

-- Brian

Re: pointers & OOP

[dennison]

In article <Pine.BSF.4.10.9905062007340.27089-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> On Wed, 5 May 1999, John Robinson wrote:
>
> I think your original claim about the inability to do OOP without pointers
> is more convincing in the weak version too, since there are some things
> like heterogeneous collections (in general) and access discriminant tricks
> (in Ada 95) that require access types, but its obvious that you can use
> OOP features in a pointerless program. How much OOP do you have to use for
> an application to be a major OOP application?

Perhaps the source of confusion is that dynamic dispatching from collections
is the main new thing that Ada95 tagged types bring to the table. The other
typical facets of OOP can be accomplished in Ada83 using minor tricks. So if
you are going to use Ada95 to do things you just couldn't do Ada83, you are
typically going to be using pointers.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: pointers & OOP

[dennison]

In article <3731fa3d.12295232@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> >Use parent-child structuring.  Internal_Updating is a protected
> >operation.  I would still consider this to be a one to one mapping,
> >although I don't use parent-child packages unless I have to.
>   If you'll allow child packages as "separate packages" it certainly
> makes "1-1 packages/classes" a lot less draconian.  OTOH, suppose you
> really wanted procedure Internal_Updating to be visible to Son and
> Daughter but *absolutely not* to any other package masquerading as
> Parent.Prodigal_Son.  Then you'd be forced to put Son and Daughter
> inside the same package as Root (unless you went to a lot of trouble
> with "doorman" routines).

That still doesn't protect against Parent.Prodigal_Son, unless you also put
that common routine in the package body.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: pointers & OOP

[dennison]

In article <3731fa3d.12295232@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> >Use parent-child structuring.  Internal_Updating is a protected
> >operation.  I would still consider this to be a one to one mapping,
> >although I don't use parent-child packages unless I have to.
>   If you'll allow child packages as "separate packages" it certainly
> makes "1-1 packages/classes" a lot less draconian.  OTOH, suppose you

That's the approach we take here. Since this is where the OpenToken packages
came from, that's the approach they take as well. I certianly hope that isn't
generally considered bad practice. It seems to work perfectly well for our
purposes.

This is perhaps a separate issue, but I also think it is a good idea for
Open Source projects to put their entire project into one parent pacakge
hierarchy. That will help prevent name clashes between packages.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: pointers & OOP

[dennison]

In article <3731fa3d.12295232@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> >Use parent-child structuring.  Internal_Updating is a protected
> >operation.  I would still consider this to be a one to one mapping,
> >although I don't use parent-child packages unless I have to.
>   If you'll allow child packages as "separate packages" it certainly
> makes "1-1 packages/classes" a lot less draconian.  OTOH, suppose you

That's the approach we take here. Since this is where the OpenToken packages
came from, that's the approach they take as well. I certianly hope that isn't
generally considered bad practice. It seems to work perfectly well for our
purposes.

This is perhaps a separate issue, but I also think it is a good idea for
Open Source projects to put their entire project into one parent pacakge
hierarchy. That will help prevent name clashes with client packages.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: pointers & OOP

[Brian Rogoff]

On Fri, 7 May 1999 dennison@telepath.com wrote:

> In article <Pine.BSF.4.10.9905062007340.27089-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > On Wed, 5 May 1999, John Robinson wrote:
> >
> > I think your original claim about the inability to do OOP without pointers
> > is more convincing in the weak version too, since there are some things
> > like heterogeneous collections (in general) and access discriminant tricks
> > (in Ada 95) that require access types, but its obvious that you can use
> > OOP features in a pointerless program. How much OOP do you have to use for
> > an application to be a major OOP application?
> 
> Perhaps the source of confusion is that dynamic dispatching from collections

Dynamic dispatching *period*. Ada-83 is even weaker than C in providing
the ability to fake OOP nicely, since it doesn't have access to
subprogram. 

> is the main new thing that Ada95 tagged types bring to the table. The other
> typical facets of OOP can be accomplished in Ada83 using minor tricks. So if
> you are going to use Ada95 to do things you just couldn't do Ada83, you are
> typically going to be using pointers.

But you don't need pointers to classwide types to get dynamic dispatch. 

FWIW, my "OO" programs in Ada do make use of pointers.

-- Brian

Re: pointers & OOP

[Ehud Lamm]

On Wed, 5 May 1999, Robert Dewar wrote:

> Far too many programmers have recently discovered encapsulation and
> data abstraction, and think that they are consequently doing object
> oriented programming.
> 
> That is why I will repeat, I do not consider encapsulation features
> per se to be part of the OOP features of a modern programming language.
> 

Indeed.

See Stroustrup's paper, linked in my "suggested on-line reading" about
"what is OOP?"

(the paper is pre 95, so its views on Ada are wrong, but the general
expalanation of conecpts is quite good).

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
http://www2.cybercities.com/e/ehud/ada

Re: pointers & OOP

[Simon Wright]

John Robinson <john@jr-and-assoc.demon.co.uk> writes:

> Agreed.  Similarly for "support" types, i.e. those built merely to
> support the declaration and/or use of the main type.  In the Booch
> component is the arc a support type or an entity in its own right? 
> The key factor (for me - and I am sure that I will get shouted at for
> saying this) is that if a type is associated with behaviour then this
> behaviour should be physically implemented in a dedicated, cohesive
> package.  

Well, in the general case I wouldn't quarrel. Just, absolute rules are
a Bad Thing, and there should always be a waiver mechanism!

In the BC.Graph case, it's clear that Graph, Arc and Vertex are
different things that must cooperate intimately to achieve the
purpose. I don't propose to second-guess Grady on this design. Just
one point -- in this case, of course child packages wouldn't be the
logical answer, because the behaviours of the three types are very
different.

Re: pointers & OOP

[John Robinson]

In article <Pine.BSF.4.10.9905062007340.27089-100000@shell5.ba.best.com>
, Brian Rogoff <bpr@shell5.ba.best.com> writes
>On Wed, 5 May 1999, John Robinson wrote:
>
>> In article <7gq27t$vnd$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-
>> dejanews.com> writes
>> >In article <MVsZ8DAT0AM3EwF3@jr-and-assoc.demon.co.uk>,
>> >  John Robinson <john@jr-and-assoc.demon.co.uk> wrote:
>> >
>> >> 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.
>
>OK, you agree with Bertrand Meyer that the class is the unit of modularity 
>I happen to think otherwise. 

I am happy to agree with Meyer.  But we all have opinions and yours are
as valid as mine.  I only wish everyone would approach life that way.

<snip>
>
>> The use (in general) of one "major" type per package goes back to my
>
>Well, now its become one "major" type per package. This is a lot weaker
>than your original claim. I might even agree with this one, 

Yes - if I have a fault it is getting suckered into replying quickly and
not reviewing the words before sending (I actually thought I used the
word "major" or "primary" or similar in the original posting - but I
probably didn't).  In any case, any implementation or secondary types I
use are not (in general) tagged types.

 ... and maybe I have more than one fault!
-- 
John Robinson
John Robinson & Associates
www.jr-and-assoc.demon.co.uk

Re: pointers & OOP

[John Robinson]

In article <3731fa3d.12295232@news.pacbell.net>, Tom Moran
<tmoran@bix.com> writes
>>Use parent-child structuring.  Internal_Updating is a protected
>>operation.  I would still consider this to be a one to one mapping,
>>although I don't use parent-child packages unless I have to.
>  If you'll allow child packages as "separate packages" it certainly
>makes "1-1 packages/classes" a lot less draconian.  

My goal is to physically separate the implementation of behaviour
associated with distinct concepts within the application domain.  I
believe this is achieved by this mapping, although again I try to avoid
parent-child packages as much as possible since, as an encapsulation
mechanism, they clearly have drawbacks.
-- 
John Robinson
John Robinson & Associates
www.jr-and-assoc.demon.co.uk

Re: pointers & OOP

[John Robinson]

In article <x7vbtfw6qbd.fsf@pogner.moho>, Simon Wright
<simon@pogner.demon.co.uk> writes
>John Robinson <john@jr-and-assoc.demon.co.uk> writes:
>
<snip>

>
>Well, in the general case I wouldn't quarrel. Just, absolute rules are
>a Bad Thing, and there should always be a waiver mechanism!
>

Agreed - all rules are meant to be broken.  But in breaking them you
should have to justify your decision.


-- 
John Robinson
John Robinson & Associates
www.jr-and-assoc.demon.co.uk

Re: pointers & OOP

[dennison]

In article <Pine.BSF.4.10.9905071853210.1885-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> On Fri, 7 May 1999 dennison@telepath.com wrote:
> > typical facets of OOP can be accomplished in Ada83 using minor
tricks. So if
> > you are going to use Ada95 to do things you just couldn't do Ada83,
you are
> > typically going to be using pointers.
>
> But you don't need pointers to classwide types to get dynamic
dispatch.
>

True. But as far as I have seen you don't *need* dynamic dispatch if you
aren't using a collection. The only other use for it I can see is to
redispatch out of a classwide operation, but I have yet to need that. Is
there something I'm missing?

--
T.E.D.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: pointers & OOP

[dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

In article <7h8v9l$dm4$1@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> dennison@telepath.com a �crit dans le message
> <7h7h9a$jdf$1@nnrp1.deja.com>...
> >True. But as far as I have seen you don't *need* dynamic dispatch if
> you
> >aren't using a collection. The only other use for it I can see is to
> >redispatch out of a classwide operation, but I have yet to need that.
> Is
> >there something I'm missing?
> >
> OK. A good example of a collection is an heterogenous file (thanks to
> streams). You can read the data and then dispatch to process them
> depending on their specific types. Where do you see pointers ?

Hmm. Yes, you have a point there. I would point out that it seems silly
to use streams for the sole purpose of implementing a collection, except
that I did just that a couple months ago...


--
T.E.D.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: pointers & OOP

[Jean-Pierre Rosen]

dennison@telepath.com a �crit dans le message
<7h7h9a$jdf$1@nnrp1.deja.com>...
>True. But as far as I have seen you don't *need* dynamic dispatch if
you
>aren't using a collection. The only other use for it I can see is to
>redispatch out of a classwide operation, but I have yet to need that.
Is
>there something I'm missing?
>
OK. A good example of a collection is an heterogenous file (thanks to
streams). You can read the data and then dispatch to process them
depending on their specific types. Where do you see pointers ?
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: pointers & OOP

[Matthew Heaney]

tmoran@bix.com (Tom Moran) writes:

> Suppose you have
>   type Root is abstract tagged ...
>   procedure Very_General(X : in out Root);
> private
>   procedure Internal_Updating(X : in out Root'class);
> and then Root has a son and a daughter
>   type Son is new Root with ...
> and 
>   type Daughter is new Root with ...
> and suppose that Son and Daughter need to use Root's Internal_Updating
> procedure.  If they are both declared in the same package as Root, no
> problem.  Even if they are declared in child packages of Root, no
> problem.  But if they are declared in truly separate packages, then
> either they cannot see Internal_Updating, or else you move
> Internal_Updating to the public part of Root's package, thus letting
> anybody see and call Internal_Updating.
>    How would you propose structuring this if you are required to have
> 1-1 package/class?

Son and Daughter go in (public) child packages.  A child has visibility
to the private part of its parent.

package Family is

  type Root is ..

private

  procedure Internal_Update ...;

end;

package Family.Sons is

  type Son is new Root with ...;

  ...

end Family.Sons;

package Family.Daughters is

 type Daughter is new Root with ...;

end Family.Daughters;

Re: pointers & OOP

[Matthew Heaney]

John Robinson <john@jr-and-assoc.demon.co.uk> writes:

> >> The use (in general) of one "major" type per package goes back to my
> >
> >Well, now its become one "major" type per package. This is a lot weaker
> >than your original claim. I might even agree with this one, 
> 
> Yes - if I have a fault it is getting suckered into replying quickly and
> not reviewing the words before sending (I actually thought I used the
> word "major" or "primary" or similar in the original posting - but I
> probably didn't).  In any case, any implementation or secondary types I
> use are not (in general) tagged types.

One time you need to combine types in the same package is when you're
using a factory method.

A factory method takes an instance of one (tagged) type, and returns an
instance of another (tagged) type.  Something like:

  function Factory_Method (O : T1) return T2'Class;

The operation is primitive for T1, and depends on types T1 and T2,
therefore both types must be declared in the same package.

Study the article Iterator and Factory Methods Combined, in the Nov 98
ACM patterns archive.  In that example a stack has a factory method that
returns an iterator.

<http://www.acm.org/archives/patterns.html>


Below is the elided spec.  There are two types in the same package, type
Root_Stack and type Root_Iterator.

Type Root_Stack has a factory method, Start_At_Top, that returns an
instance of an iterator appropriate for iteration over that kind of
stack.

   generic
      type Item_Type is private;
   package Stacks is

      type Root_Stack is
        abstract tagged limited null record;  -- type T1


      procedure Push
        (Item : in     Item_Type;
         On   : in out Root_Stack) is abstract;

      procedure Pop
        (Stack : in out Root_Stack) is abstract;

      ...


      type Root_Iterator is
        abstract tagged null record;          -- type T2

      function Start_At_Top
        (Stack : Root_Stack)
         return Root_Iterator'Class is abstract;  -- the factory method


      function Is_Done
        (Iter : Root_Iterator)
        return Boolean is abstract;

      function Get_Item
        (Iter : Root_Iterator)
         return Item_Type is abstract;

      procedure Advance
        (Iter : in out Root_Iterator) is abstract;

      ...

   end Stacks;



Declaring the data structure and its iterator together in the same
package is a very natural idiom.  

The reason Booch didn't have two types per package (data structure type
plus iterator type) in his component library is that he didn't have
active iterators.  

Re: pointers & OOP

[Matthew Heaney]

John Robinson <john@jr-and-assoc.demon.co.uk> writes:

>>Very often putting multiple types into a single package solves in a
>>neat and clean way nasty problems that simply don't have neat solutions
>>in other languages.
> 
> Such as?  

Here's one reason: giving types mutual access to each other's
representation.  It's like a "friend" in C++.

Sometimes, two types are just highly cohesive, and you never use one
with also using the other.  A classic example is a data structure and
its (active) iterator.


> The use (in general) of one "major" type per package goes back to my
> earliest days with Ada 83, and is of course inherent in Booch's
> original "Software Engineering with Ada" text which was so influential
> in the adoption of ADT-based programming in the Ada world.

But if Booch had provided active iterators, then he would have declared
them together in the same package.


> This approach, which I have (so far) successfully carried over into
> Object Oriented Ada 95 code, brings a number of benefits
> (e.g. straightforward traceability between analysis and code, very
> clear separation of concerns etc).

No one is arguing that you put just any types together in the same
package.  We all agree that that is a bad thing (because it causes
unnecessary compilation dependencies).


> However, I am open to other approaches, if the benefits are clear.

It's called a "package" for a reason -- because it holds in one place
all the entities associated with an abstraction.

Be careful not to confuse a module with a type.  In Ada, an abstraction
is provided by a package (or hierarchy of packages).  That one or more
types are used to implement the abstraction, well, that's just a feature
of the implementation.  It's the package (really, objects) that's the
important thing.

That's why when you trace analysis or design artifacts to code, you
should really be tracing them to packages with state, not types.  It's
objects that are important -- types (even ADTs) are mere implementation
details.

You can (and should) implement abstractions using a package only,
without using any abstract data types.  This is how you implement
well-known objects, a static abstraction whose cardinality is known up
front.  A singleton is the limiting case of a well-known object whose
cardinality is one.

The package Ada.Text_IO is a good example of an abstraction that
contains multiple types and static state.  The abstraction is "text
i/o", not just "file type".

Package Text_IO contains these types:

  File_Type
  Count
  Positive_Count
  File_Mode

and at least three local variables:

  Standard_Input
  Standard_Output
  Standard_Error

See my articles about singletons/well-known objects in the Feb 97 and
Jun 98 archives.


> >You are tieing BOTH hands behind your back if you adopt this completely
> >unnecessary and damaging restriction.
> 
> I would be very interested in seeing a specific example of why this is
> damaging.  Perhaps a specific reference to the patterns archive cited
> by Matthew?


Study the article Iterator and Factory Methods Combined, in the Nov 98
ACM patterns archive.  In that example a stack has a factory method that
returns an iterator.

See also the examples and discussions of the Observer pattern, in the
March 99 archive.  For example, here's the spec:

  package Subjects_And_Observers is

     type Root_Subject_Type is
       abstract tagged limited private;

     procedure Notify 
       (Subject : in out Root_Subject_Type'Class);


     type Root_Observer_Type 
          (Subject : access Root_Subject_Type'Class) is
       abstract tagged limited private;

     procedure Update 
       (Observer : access Root_Observer_Type) is abstract;

    ...

  end Subjects_And_Observers;



One abstraction, one package, two types.  

As I explained to Ed Falis (on Mar 19, 1998):

(start of excerpt)
> Ed Falis <falis@ma.aonix.com> writes:
> Third, I just plain dislike placing the field for linking onto the observers
> list into the observer.  This is more an aesthetic issue than anything else,
> but it makes implementation of the observer list just a little too visible
> for my taste.

I take the attitude that when you have mutually dependent types,
together in the same package, that the types must be treated as a unit.

The subject and observer types are highly cohesive parts of a larger
abstraction ("publish subscribe"), and you can't study them
independently of each other.
(end of excerpt)


<http://www.acm.org/archives/patterns.html>

Matt

Re: pointers & OOP

[Ed Falis]

On Fri, 14 May 1999 05:17:01 GMT, Matthew Heaney <matthew_heaney@acm.org> wrote:
> As I explained to Ed Falis (on Mar 19, 1998):
> 
> (start of excerpt)
> > Ed Falis <falis@ma.aonix.com> writes:
> > Third, I just plain dislike placing the field for linking onto the observers
> > list into the observer.  This is more an aesthetic issue than anything else,
> > but it makes implementation of the observer list just a little too visible
> > for my taste.
> 
> I take the attitude that when you have mutually dependent types,
> together in the same package, that the types must be treated as a unit.
> 
> The subject and observer types are highly cohesive parts of a larger
> abstraction ("publish subscribe"), and you can't study them
> independently of each other.
> (end of excerpt)
> 
> 
> <http://www.acm.org/archives/patterns.html>
> 
> Matt


Not sure exactly where "explainiing" came into it, "Magister", since my alternative also packaged the observer, observable and an event type together.  My 
disagreement was with the inclusion of the implementation field of the observable into the observer.

We have a philosophical difference on this.

In general, I tend to view abstractions as compositions of other abstractions.  In this particular case, you're right - it doesn't make sense to consider the roles of 
observer and observable independent of the publish-subscribe pattern.  But where does one draw the line?  When one composes an abstraction from other 
abstractions, do we then put all of it into a package?  Do we design it "top-down" so that the components of the larger abstraction can't be extracted and 
mixed at other levels of granularity, because they contain parts of the implementation of other roles?  Or do you figure one will always use multiple inheritance to 
mix in the pattern into application abstractions (that's rhetorical, because I don't think you buy it, though I often do).   The alternative seems to me to be custom 
crafting each "instantiation" of the pattern into a given design, which is what I've seen you do in many of your examples.  What happened to reuse, then?

Yes, I realize that a pattern is not a library or a design or software per se.  But that basic assumption doesn't contradict the desirability of good, flexible and 
_easily composable_ components that provide common implementations of patterns.

As time goes by, I've personally begun to question whether the flexibility of Ada's splitting of modularity and extension is worth the amount of plumbing one has 
to explicitly deal with when composing abstractions.  Indeed, there are some nice aspects to it, but it seems to add extra noise to the source code in the normal 
case, in order to accommodate the possibilities in less common contexts.  (Still not as noisy as the bulk of Java code one sees, though more noisy than Java's 
OO capabilities).  

Yeah, that's very subjective.  But frankly, I find myself having to work a lot harder to understand patterns I've seen "instantiated" in Ada than in some other 
languages.  And I'm no dope - I've been doing Ada OO for almost 5 years now, and using the language in general for a lot longer than that.  So, the approach 
mitigates against understandability for me - the "chunking" of independent concepts and abstractions seems too large.

Or maybe I'm just getting lazy in my old age, and don't like to have to work so hard to understand and use things (especially if I think there are simpler ways).

- Ed

Re: pointers & OOP

[David Botton]

The article is also available at:

http://www.adapower.com/alg/activeiter.html

David Botton


> Study the article Iterator and Factory Methods Combined, in the Nov 98
> ACM patterns archive.  In that example a stack has a factory method that
> returns an iterator.