Re: OO Preprocessor for Ada

Re: OO Preprocessor for Ada

[dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!math.ohio-st]

riley@cl2.cl.uh.edu (JOHN D. RILEY) asks
> Is anyone familiar with a preprocessor for translating a fully object
> oriented notation into Ada 83?

Classic-Ada from Software Productivity Solutions is pretty much what you
want.  Try them at 407-984-3370.

At WAdaS '93 last month EVB announced at their hospitality booth that
they are porting to Ada an existing C product called ITASCA.  I know
very little about it.  Try EVB at 301-695-6960.

Art Evans
----------------------------------------------
Arthur Evans, Jr, PhD           Ada Consultant
461 Fairview Road
Pittsburgh PA  15238-1933
412-963-0839
ae@sei.cmu.edu

Re: OO Preprocessor for Ada

[Tucker Taft]

In article <14JUL199318572374@cl2.cl.uh.edu> RILEY@cl.uh.edu writes:

> . . .
>I realize that Ada 9X will support (by most definitions) OOP.
>However the 9X implementation will not have the "look and feel"
>that OOProgrammers expect. 

It would be interesting to have more explanation of this.  There
are many "OOP" programmers who have looked at Ada 9X, and most of them
made no mention of any "look and feel" problems (of course, they
might have *other* complaints ;-).  Could you be a bit more specific?

Here are some possible look and feel issues:

  1) Prefix notation  
      i.e. blah.operation(params) instead of operation(blah,params)

      Note that CLOS doesn't use prefix notation, and with "friends" in
      C++, prefix notation is abandoned when it is useful to do so
      (e.g. for symmetric handling of binary operators).

  2) Combining type and module into a single "class" construct

      Many OOP languages don't make this combination.
      In particular, the "Object-Pascal-like" languages typically
      have an "object type" and then some other kind of module
      (e.g. a "unit" in Turbo Pascal with Objects, or a "module" in Modula-3).
      Even good old C++ seems to be heading toward a separation of
      module and type, with the "namespace" proposal for ANSI/ISO C++.

Are there some other "look and feel" issues you had in mind?
Which "look and feel" issues in your view make a significant 
difference to the usability of an OOP language?

> . . .
>John D. Riley

Thanks in advance...

S. Tucker Taft     stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: OO Preprocessor for Ada

[Robert I. Eachus]

In article <15JUL199315464091@cl2.cl.uh.edu> riley@cl2.cl.uh.edu (JOHN D. RILEY
) writes:

  > I think your suggestion is this:

  > Package X is
  >    type object is ?whatever?;
  >    Procedure OP1 (Q : object);
  > end X; 

  > Don't I still need to pass the object as a parameter?

  If you care about this, the Ada solution has always been to use
generic package instantiations as objects:

  generic
  package X is
    procedure OP1;
  private
    type object is -- or can appear in the package body, or the state
		   -- variable can be declared separately instead of
		   -- as a record type...

  package Y is new X;
  ...
  Y.OP1;
  ...

    The rules about where tagged types can be declared in Ada 9X will
limit where instantiations can appear if they include tagged types,
but none of this depends on tagged types.  (It might be nice to have
generic instances as first class objects, but that is a different
discussion.  In Ada 83 you can do it with task types, but the run-time
overhead is huge.)

   also suppose I have:

   Package Y is
     type object is ?whomever?;
     Procedure OP_A (Q : object);
   end Y;

   > now I encounter class Z which is logically the union of X and Y.

   > I would like to do something like:

   > Package Z is

   > COMBINES (X,Y);
   >  .....
   > end Z;

   generic
   package Z is
     procedure OP1;
     procedure OP_A;
   end Z;

   (Note that in this case you normally don't want to use the new Ada
9X generic package parameters as they simplify declaring Z at the cost
of extra work at instatiation time.)

   with X,Y;
   package body Z is
     package My_X is new X;
     package My_Y is new Y;
     procedure OP1 renames My_X.OP1;
     procedure OP_A renames My_Y.OP_A;
     -- new feature in Ada 9X.  In Ada 83 you have to use call-throughs.
   end Z;

  > so now I could call both Z.OP1 and Z.OP_A to act on an object of class Z.

    All done...

    I have designed and written several applications using this style
of OOP in Ada 83.  It works very nicely for simulations where you have
a small number of objects which are individualized through generic
parameters. (The number of objects need not be constant.)  Especially
in Ada 83 though, it helps to have tools to automagically generate the
bodies for packages which do call-throughs.  (Steve Litvintchouk has
some gnu emacs extensions that help a lot.)  In Ada 9X both the
package parameters and renaming as bodies will ease the pain a lot.
(I'm also hoping that protected objects will provide a better way of
making these object types first class.)
   

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: OO Preprocessor for Ada

[news.cnri.reston.va.us!newsserver.jvnc.net!louie!balin.cis.udel.edu!carro]

In article <15JUL199315464091@cl2.cl.uh.edu> RILEY@cl.uh.edu writes:
>Thanks for the suggestions, but I still have a couple of questions:
>
>In article <CA7zB0.LuI@inmet.camb.inmet.com>, stt@spock.camb.inmet.com (Tucker
 Taft) writes..
>>>>Here are some possible look and feel issues:
>>>> 
>>>>  1) Prefix notation  
>>>>      i.e. blah.operation(params) instead of operation(blah,params)
>> 
>>However, this breaks down for binary operators.  One nice
>>feature of CLOS and Ada 9X, is that binary operators are handled
>>symmetrically, without any need for non-inheritable "friends."
>
>How does Smalltalk handle binary operators?
>I don't think it involves "friends".

Smalltalk uses a trick called multiple dispatch.

The idea is, you dispatch on the first parameter, which calls a method
which selects one of a group of available methods, and dispatches
one of those on the second parameter.

Bad explanation. Let me use an example:
  	a + b

What this does is send the message "+" with the argument "b" to the
object "a". Now, none of the types are known statically, so the compiler
cannot select the correct method for adding an object of type "TypeOfA" to
an object for type "TypeOfB". But "a" does know it's own type. So it
dispatches again, using that information: the method "+" for object
"a" dispatches again, and does:

	b addATypeA: a

So you've dispatched twice: once on the type of A (in the method "+")
and once on the type of b (in the method "addATypeA").

It's rather kludgy, but it does do what you need. But I think that
multimethod binding (which if I'm reading things correctly Ada9x does)
is prefereable.

	<MC>
-- 
|| Mark Craig Carroll: <MC>     ||"I live to see my fondest dreams realized,
|| CIS Grad, Univ of Delaware   || Of living under the sights and sounds of
|| PGP key available by finger  || the gifted, Who gave so much to me"
|| carroll@udel.edu             ||   - _Feed_the_Fire_, Happy Rhodes

Re: OO Preprocessor for Ada

[David Emery]

>However the 9X implementation will not have the "look and feel"
>that OOProgrammers expect. 

Huh?  Which "OOProgrammers" do you mean?  C++ has a very different
"look and feel" from either SmallTalk or CLOS.  I believe that Ada9X
is a substantial improvement over C++, SmallTalk and CLOS, and "viva
la difference!".  (pardon my lousy French. :-)

				dave

Re: OO Preprocessor for Ada

[cis.ohio-state.edu!math.ohio-state.edu!darwin.sura.net!source.asset.com!c]

In article <15JUL199315464091@cl2.cl.uh.edu> RILEY@cl.uh.edu writes:
>Thanks for the suggestions, but I still have a couple of questions:
>
>In article <CA7zB0.LuI@inmet.camb.inmet.com>, stt@spock.camb.inmet.com (Tucker
 Taft) writes..
>>>>Here are some possible look and feel issues:
>>>> 
>>>>  1) Prefix notation  
>>>>      i.e. blah.operation(params) instead of operation(blah,params)
>> 
>>However, this breaks down for binary operators.  One nice
>>feature of CLOS and Ada 9X, is that binary operators are handled
>>symmetrically, without any need for non-inheritable "friends."

This is indeed the benefit of having the "target object" for 
an operation be passed as an explicit parameter to an 
operation.  But in the cases where an operation is performed on 
a single object (i.e., unary operations), some may feel the 
syntax that John Riley is searching for would make Ada "more 
object-oriented" (i.e., where the target object is _implicitly_ 
passed by the object prefix notation).  So...

>>>>  2) Combining type and module into a single "class" construct
>
>>Clearly these two things (prefix notation and type=module) are
>>not essential to OOP, since there are several "true" OOP languages
>>that don't have them.  Nevertheless, if one finds these particular
>>"look and feel" characteristics useful, one possibility I have seen 
>>is to have exactly one (tagged) type per package, and use the package
>>name as the equivalent of the "class" name.  The actual type name
>>is then something innocuous like "object" or "class" or
>>some such thing.  This gives you both a prefix-like 
>>notation (e.g. pkg.operation(param1, param2, ...)) and
>>provides the one-type-per-module organization.

This is precisely the approach that we are using in our OOD 
courses.  It simply removes the need to contrive distinct names 
for the package and the object's type.  I first saw this 
technique in Colin Atkinson's textbook, "Object-Oriented Reuse, 
Concurrency, and Distribution" where he addresses how to map 
DRAGOON's class construct to standard Ada 83 syntax.  Note that 
the technique works similiarly for both Ada 83 and 9X.  

This naming convention goes further to combat the 
superficial distinctions that often result between package and 
type names:

  package FIFO is     package Stacks is     package Motor_Vehicle is
    type Queue is ...   type Stack is ...     type MV is ...
    
     (synonyms)         (pluralization)    (acronyms and abbreviations)

When one desires a "type = module" semantics, such an 
approach is very appropriate.

John Riley responded to Tucker's remarks with an example: 

>I think your suggestion is this:
>
>Package X is
>   type object is ?whatever?;
>   Procedure OP1 (Q : object);
>end X; 

This is indeed the basic approach.  However, several other 
naming conventions may be introduced to further remove 
arbritrary distinctions in the implementations.  I'll take the 
liberty to restructure and complete John's short example:

   package X is -- Represents a class X identified in OOA/OOD
      type Object is tagged limited private; -- Represents a "root class"
      procedure Create (Instance : in out Object);    -- "constructor"
                        P1       : in     Integer);
      procedure Modify (Instance : in out Object;     -- "modifier"
                        P1       : in     Integer;
      function P1 (Instance : Object) return Integer; -- (direct) "selector"
   private
      type Object is tagged
         record
            P1 : Integer;
         end record;
   end X;

As with many Ada 83 OOD methods, we use a private type to 
enforce abstraction and encapsulation principles.  In Ada 9X, 
we can use a _tagged_ private type to begin an inheritance 
hierarchy.  Note that each operation specification must give 
some name to the formal parameter that represents the target 
object.  Since this parameter is also often arbitrarily named, 
we can simply pick one and standardize on it.  We use the name 
"Instance."  Smalltalk programmers may use "Self," and C++ 
programmers "this."  In any event, standardizing on one name 
further supports the desire to not have to worry about it in 
the first place.

John also poses the question,

>Don't I still need to pass the object as a parameter?

The answer is, yes, you do.  But by structuring packages in 
this way, the following syntax results in client code:

   with X, Text_IO;
   procedure Some_Client is
      An_Object : X.Object;
      P : Integer;
   begin
      X.Create (Instance => An_Object, P1 => 7);
      X.Modify (An_Object, P1 => 3);
      P := X.P1 (An_Object);
      Text_IO.Put ("The value of P1 is: ");
      Text_IO.Put ( Integer'IMAGE(P) );
   end Some_Client;
   
We see that the general syntax for declaring such objects is:

   target_instance : class_name.Object;
   
and the general syntax for "sending messages" is:

   class_name.operation_name (target_instance, other_parameters);

So this technique does provide for a sort of prefixing that 
John and others may be looking for.  The difference is that 
each operation is prefixed, not by the object name, but by the 
object's _class_ name.  I think that this approach addresses 
the basic premise of John's concerns, which is to "emphasize the 
connection between objects and operations."  This technique 
actually goes a step further in that it addresses the 
connection between objects _and their classes_, which assists 
in undertanding the modularity and visibility of objects and 
classes as well.  The syntax always documents the "class 
package" from which an object has been generated and where the 
object's operations are defined.

This particular subject happens to be the theme of a paper that 
I will be presenting at Tri-Ada in September.  Anyone that is 
interested may contact me by E-Mail for more details.

-- 
Gary J. Cernosek
Fastrak Training Inc.
Houston Office: (713) 280-4768
E-mail: cernosek@source.asset.com

Re: OO Preprocessor for Ada

[cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!vixen.cso.u]

...stuff deleted
>
>   with X, Text_IO;
>   procedure Some_Client is
>      An_Object : X.Object;
>      P : Integer;
>   begin
>      X.Create (Instance => An_Object, P1 => 7);
>      X.Modify (An_Object, P1 => 3);
>      P := X.P1 (An_Object);
>      Text_IO.Put ("The value of P1 is: ");
>      Text_IO.Put ( Integer'IMAGE(P) );
                     ^^^^^^^^^^^^^^^^
Since X.Object is a tagged limited private type, can you 
actually do an Integer'IMAGE on P?

{I liked your post, but I'm just trying to make sure I understand
the example}

>   end Some_Client;
>   

Ken.

Re: OO Preprocessor for Ada

[agate!spool.mu.edu!sol.ctr.columbia.edu!emory!europa.eng.gtefsd.com!darwi]

In article <CBz2Cx.8q2@cs.uiuc.edu> rowe@cs.uiuc.edu (Kenneth E. Rowe) writes:
>
>...stuff deleted
>>
>>   with X, Text_IO;
>>   procedure Some_Client is
>>      An_Object : X.Object;
>>      P : Integer;
>>   begin
>>      X.Create (Instance => An_Object, P1 => 7);
>>      X.Modify (An_Object, P1 => 3);
>>      P := X.P1 (An_Object);
>>      Text_IO.Put ("The value of P1 is: ");
>>      Text_IO.Put ( Integer'IMAGE(P) );
>                     ^^^^^^^^^^^^^^^^
>Since X.Object is a tagged limited private type, can you 
>actually do an Integer'IMAGE on P?

Note that I am simply taking the 'IMAGE of an object P, which is itself
of type Integer.  P is assigned the result of the selector call, seen a
couple of lines before the one in question.  Since the function X.P1
returns a value of type Integer, this statement is OK.  But you're
right, one cannot take the 'IMAGE of a private object.

Note that I could have eliminated the local variable P altogether:

   Text_IO.Put ( Integer'IMAGE (X.P1(An_Object) ) );

One could argue about which style is more "readable;" but in any event,
the 'IMAGE attribute must be applied to an Integer-typed value.

-- 
Gary J. Cernosek
Fastrak Training Inc.
Houston Office: (713) 280-4768
E-mail: cernosek@source.asset.com

Re: OO Preprocessor for Ada

[Graham Matthews]

<15JUL199315464091@cl2.cl.uh.edu> RILEY@cl.uh.edu writes:
> >>However, this breaks down for binary operators.  One nice
> >>feature of CLOS and Ada 9X, is that binary operators are handled
> >>symmetrically, without any need for non-inheritable "friends."
cernosek@source.asset.com (Gary J. Cernosek) writes:
> This is indeed the benefit of having the "target object" for 
> an operation be passed as an explicit parameter to an 
> operation.  But in the cases where an operation is performed on 
> a single object (i.e., unary operations), some may feel the 
> syntax that John Riley is searching for would make Ada "more 
> object-oriented" (i.e., where the target object is _implicitly_ 
> passed by the object prefix notation).  So...

I don't mean to sound too wildly incredulous, but surely people don't 
really believe that people think "X is more OO because of some
syntax that passes the target object implicitly"?!?!?! Or am I
over-estimating people's common sense?

graham

-- 
You can tell how far we have to go when FORTRAN is the language of
supercomputers.
	-- Steven Feiner

Re: OO Preprocessor for Ada

[cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!vixen.cso.u]

Obviously you're right, I was just asleep in the front row again.

I guess what this example triggered was painful memories of trying 
to provide text_io capabilities when you declare a limited private type.
Does anyone have an elegant example of how to do this with 9X with tagged
types and text_io generics?

I guess to further define the problem, using this running example,
how can I provide a text_io print capability of an object of type X.Object?
(i.e. how do I print An_Object directly?).

Ken.

-------------------------------------------------------------------------------
Ken Rowe
Visiting Lecturer				1304 W. Springfield Avenue
Department of Computer Science			Urbana, IL 61801-2987
University of Illinois at Urbana-Champaign	(217) 244-7235
rowe@cs.umbc.edu