Re: ADA Objects Help!

Re: ADA Objects Help!

[Mats Weber]

In article <3ff186$c19@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) wrote:

> I can't get excited about the difference between
> 
>   a.b(c);
> 
> and
> 
>   b (a, c);
> 
> I actually much prefer the second, because why introduce a new syntax when
> none is needed, and type extension and dynamic dispatching are MUCH more
> general concepts than a narrow view of objects and methods would suggest.

It is not a new notation: it exists for tasks and you can write a.b(c)
when a is a task object. As there are tasks and task types, why not
packages and package types ?

Re: ADA Objects Help!

[Robert Dewar]

"why not packages and package types"

why not indeed? it is always interesting to see people joining the party
late and treading previously trodden realms :-)

Yes, this is an attractive idea, one that some important Ada folks have
championed, and which has been examined extensively.

Basically the conclusion is that following this line of thought leads
(a) to excessive complexity, it is very tricky to work out all the
 ramifications 

(b) to a confusion of concepts, packages are not happy extended in this
 direction, and it causes a confusion (unification???) of types and packages.
 The final decision of the Ada design is that this would have confused rather
 than unified.

(c) the building of the OOP notions on top of derived types is much more
 powerful and general, and avoids some of the limitations that come from
 a narrow, distinguished object approach.

Tuck may want to add to this, clearly a full answer will saturate the internet
bandwidth for some time!

Re: ADA Objects Help!

[Robert M. Wilkinson]

In article <D2H5un.FEr@nntpa.cb.att.com>,
Kenneth Almquist <ka@socrates.hr.att.com> wrote:
>
>C++ has two procedure calling syntaxes.  It is possible to write either
>   display(myptr);
>or
>   myptr->display();
 
Please note that these have *entirely* different semantics; they are not
merely "two forms of syntax" for the same thing. 
 
 
>These both call a procedure, passing the value myptr as the argument.
>In contrast, Ada provides only a single procedure call syntax.
>
>When you declare a procedure in C++ you specify which syntax will be
>used to call the procedure.
 
Again, there is much more to it than just the syntax.  One is a member
function, the other is a plain-old function.  Big, big, difference. 
 
 
>As a result, having the two syntaxes
>provides the following functionality:
>
>1.  Both Ada and C++ provide overloading, but in C++ it is possible for
>    two overloaded routines to have the same argument types as long as
>    the calling syntax is different.  The two calls to "display" which
>    appear above call different routines.
 
Of course they do.  One calls a member function, the other does not.  Think
of it as calling two functions with the same signature, but residing in
different packages.  
 
 
>2.  If you establish a suitable convention, the choice of calling syntax
>    can be used to convey additional information about the procedure.  I
>    haven't been able to devise a useful convention, but that doesn't mean
>    that a useful convention does not exist.
 
It is not a question of convention at all. 
 
 
>My own opinion, formed before I knew anything about Ada 9X, is that this
>functionality is not useful, and thus having two syntaxes increases the
>complexity of the language without providing any corresponding benefit.
 
Perhaps you need a better C++ book.  If you cannot see the need for 
member functions, which is the heart and soul of C++, then you definitely
do not understand the language. 
 
-- 
____________________________________________________________________________
  
Rob Wilkinson                                              wilkinso@gdls.com
____________________________________________________________________________

Re: ADA Objects Help!

[Mats Weber]

In article <3fjk7t$2km@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) wrote:

> "why not packages and package types"
> [...]
> Basically the conclusion is that following this line of thought leads
> (a) to excessive complexity, it is very tricky to work out all the
>  ramifications 

I can't see why unless you provide more precise information. Package
types, _provided they cannot export types or exceptions_, are basically
equivalent to record types, except that they can export subprograms (to be
used as methods).

> (b) to a confusion of concepts, packages are not happy extended in this
>  direction, and it causes a confusion (unification???) of types and packages.
>  The final decision of the Ada design is that this would have confused rather
>  than unified.

I think this is more a question of personal preference.

> (c) the building of the OOP notions on top of derived types is much more
>  powerful and general, and avoids some of the limitations that come from
>  a narrow, distinguished object approach.

Package types do not preclude the use of derivation + class-wide types as
the inheritance mechanism (I think). I built my proposal using subtyping
as the inheritance mechanism, much along what N. Cohen did in his paper on
extendible record types. If I re-did it now, I'd use another mechanism,
probably something like Modula-3's subtyping rules.

Mats

Re: Ada Objects Help!

[Robert Dewar]

"How can Ada be object oriented if you always have to pass the data to the
function?"

I have a clearer version of this question

"How can Ada be object oriented if the second and third characters of its
 name are not special characters?"

:-)

Re: ADA Objects Help!

[Norman H. Cohen]

In article <Mats.Weber-1901951739360001@mlma11.matrix.ch>,
Mats.Weber@matrix.ch (Mats Weber) writes: 

|> In article <3fhggr$11dp@watnews1.watson.ibm.com>, ncohen@watson.ibm.com wrote: 
|>
|> > Because, unlike task units, package units export declarations for use
|> > outside.
|>
|> Well, tasks export entries, which are usable outside just like subprograms
|> exported from packages.

True enough.  The entries are per-type entities, whose declarations are
elaborated once for each task type.  (This is noticeable by the fact that
entry-family discrete ranges are elaborated once per task type, not once
for each object of the type.) Entities declared in the declarative part
of the task body are per-object entities, whose declarations are
elaborated once per object.

The distinction I was trying to make (alhtough I wasn't very clear about
it) was about per-object entities: The entities declared in a package-
type declaration would be exported by each object in the package type,
unlike the per-object entities of a task type.

|> > Each time an object of a package type is created, these
|> > declarations would have to be elaborated again, so that identically
|> > declared entities exported by different objects of a package type would
|> > be distinct.  For example: 
|> >
|> >    package type PT is  -- THIS IS NOT VALID ADA XX for XX <= 95 !!!!!!
|> >       N: Integer := [some nonstatic expression];
|> >       type T is array (1 .. N) of Integer;
|> >    end PT;
|> >
|> >    Package_1, Package_2: PT;
|>
|> The declaration for N does not cause a problem. It would be treated just
|> like a record component declaration with a default initial value (i.e. the
|> nonstatic expression is evaluated at each elaboration of a PT).

This is beginning to look suspiciously like a generic package.  Generic
templates are the only program units in Ada with the property that
declarations inside the program-unit declaration are not elaborated as
part of the elaboration of the program-unit declaration.

|> Type, subtype, and exception declarations would not be allowed within
|> package types. We don't want dynamic creation of types.

The term package type is beginning to look like a misnomer.  The
instances of these types are far more restricted than packages are.
In fact they are even more restricted than generic packages.
A package that cannot provide types is little more than a record.

|> > Package_1.T and Package_2.T are distinct types.  The same applies to any
|> > interesting entity exported by Package_1 and Package_2.  So what do we
|> > gain by defining them to belong to the same type?
|>
|> What do you mean by `interesting entity' ?

Just about anything other than renamed views and named numbers.  In
particular, if there is a subprogram with an operation of a type declared
in the package-type declaration, there is a distinct subprogram, with a
distinct profile, for each object of the package type.  That should make
overloading resolution interesting.  (There's that word "interesting"
again, in a different sense this time!)  Thus you are right to rule out
type declarations in package-type declarations, but it makes package
types little more than record types.

|> I have just completed my thesis and part of it is a proposal for object
|> oriented Ada based on package types.

Aren't you glad I wasn't on your thesis review committee? ;-)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Ada Objects Help!

[Mark S. Hathaway]

> In article <1995Jan16.132400@lglsun.epfl.ch>,
> nebbe@lglsun.epfl.ch (Robb Nebbe) writes:

>> In article <3f9g1u$j4m@nps.navy.mil>, swdecato@nps.navy.mil writes:

>> I wan't to duplicate the following C++ code in Ada.
>> 
>> -------------------------------------------------------------------
>> #include <iostream.h>
>> class myclass {
>>    public:
>>        myclass(int);
>>        void display();
>>    private:
>>        int dataelement;
>>    };
>> 
>>    void myclass::display() {
>>       cout << dataelement;
>>    }
>> 
>>    int main()
>>    {
>>    myclass *myptr = new myclass(10);
>>    myptr->display();
>>    return 1;
>>    }
>> ------------------------------------------------------------------------

> As usual the major problem is how much of the information in your
> example is noise and how much is really something you would like
> to know. With out more information on the context I'm going to make
> a _guess_ as to what you want to know (correct me if I'm wrong).
> 
> package P is  -- Just the specification
>    type T is tagged private;
>    function Create( X : Integer ) return T;
>    procedure Display( X : T );
> private
>    type T is tagged
>       record
>          Data_Element : Integer;
>       end record;
> end My_Package;
> 
> with P; use P;
> procedure Example is
>    Object : T'Class := Create( 10 );
> begin
>    Display( Object );
> end Example;
> 
> Semantically this is probably as close as you can get to your C++
> example. In Ada the pointer isn't needed to dispatch since Ada
> differentiates between specific types and class-wide types. Moreover,
> in Ada there aren't any problems with your objects getting truncated
> so this solution works just fine. There are also other minor variations
> possible, depending on what you really want to accomplish.

>> How can Ada be object oriented if you always have to pass the data to the
>> function? 

> In C++ you must also pass the data to a function; the only difference
> is in the syntax. Object.Operation; is no different semantically than
> Operation( Object );


These examples looks odd to me.  I'm not very knowledgeable of Ada or C++,
but I know pornography when I see it (oops, that's another discussion).  :-)

It's not obvious if 'myclass(int)' is creating a list of objects of type
myclass or if it's assigning 10 --> dataelement.  It's not very eloquent.
Then the Ada example changes 'myclass(int)' to 'Create(X : Integer) return T'
with the added complexity of defining T.  It looks wrong or overly complex.
And it's comparable in length to the C++ version only because the class
implementation isn't given.  Does the Ada example even create an object?

Here's my idea of how it should look.

spirit myclass is
  proc assign ( x is in integer );  -- assign value referenced by x to myclass
  proc display ();
end myclass;

body myclass is
  var dataelement is integer;
  proc assign ( x is in integer ) is
    dataelement := x;
  end assign;
  proc display () is
    out.write(dataelement);
  end display;
end myclass;

program example1 is
-- This example demonstrates the pointer method the C++ example used.
  var op is pointer to myclass;
begin
  new(op);      -- create instance of an object of type to which op can point
  op->assign(10);
  op->display();
end example1.

program example2 is
-- This example demonstrates the direct usage of an object.
  obj o is myclass;      -- create one instance of the object
begin
  o.assign(10);
  o.display();
end example2.

Isn't this closer to what the C++ example is "saying"?


Mark S. Hathaway       <hathawa2@marshall.edu>

Re: ADA Objects Help!

[Robert Dewar]

Mats, if you don't see any problems in package types, then you have not even
started to scratch the surface. I don't know if there are any easily
accessible written discussions of this issue or not. The amount of
discussion that has occurred on this issue would certainly fill many books.
It would be helpful to have a summary so that people don't keep rewalking
the same path without knowing where it leads, but I certainly don't have
time to do it!

Re: ADA Objects Help!

[Robert Dewar]

Rob Wilkinson, if you cannot see that from a purely semantic point of view
there is nothing particularly special about member functions, then maybe
it is you who need a better C++ book.

You are viewing them through a semantic filter which says that you will
view these member functions in a special way, corresponding to a particular
paradigm that you (and the language design!) have in mind. However, if you
can manage to take a more basic viewpoint, you will see that member functions
are just functions, nothing more and nothing less. THey have a special
syntax and visibility, but that does not mean they are semantically
fundamentally different from ordinary functions.

YOu may just be to wrapped up in your viewpoint to see the point that several
people have made to you, certainly it does not seem to be registering.

Basically we have functions that can be used as ordinary functions and 
functions that you want to associate with a particular "object". Note
incidentally that at the language level, C++ does not have objects, it
has special structures that are called classes that may be particularly
well suited for the representation of objects, but they are not objects,
because the concept of object has to do with programming paradigms, NOT
with the language design.

In Ada 95, this same programming paradigm (objects and member functions,
probably better called methods in this context, since member functions is
just a syntactic designation), are represented by tagged types and associated
primitive subprograms with controlling arguments.

Just as in C++, classes and member functions may be used to represent
objects and methods, but of course have many other uses, in Ada 95,
tagged types and primitive operations of these types may be used
to present objects and methods.

The semantics in this correspondence are pretty much identical, although the
Ada 95 model is a little more flexible in that one can have more than one
appearence of the tagged type in the parameter list, which together act as
a controlling operand. THis is not important if you are strictly representing
objects and methods, but can be very useful in other contexts.

I think the reason that no one understands what you are saying, and 
consequently that you are getting frustrated, is that you are starting
out from some fundamental assumptions that are false:

   classes in C++ represent objects, false, they can be used to represent
   objects, but that is a programmer choice.

   member functions in C++ are methods. again false, they can be used for
   this purpose, but that is a programmer design choice.

Then you add to it your apparent feeling that this particular usage is
critical enough that it is important to give it a separate syntax. The
trouble is that this introduces multiple syntaxes for identical semantic
concepts (at the language level), and in the Ada 95 design we consider
it an advantage that no separate syntax is used. It leads to a much more
flexible capability, with all the power of the corresponding C++ constructs
and additional capabilities.

In C++, classes are often used for purposes other than the representation of
objects. For instance, in the absence of name spaces, they are used to
represent packaging of entities quite often, and in this context the special
syntax for member functions can definitely get in the way (e.g. if the
function is a binary operator operating on the class type).

Re: Ada Objects Help!

[Tucker Taft]

In article <3fopnh$9k1@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:

>"How can Ada be object oriented if you always have to pass the data to the
>function?"
>
>I have a clearer version of this question
>
>"How can Ada be object oriented if the second and third characters of its
> name are not special characters?"
>
>:-)

As Robert is implying, object-oriented languages differ in both significant
and insignificant ways.  Clearly you need to identify the object which
is the "target" when invoking an operation.  In C++ and Smalltalk, this object
is identified in a "prefix" of the invocation of the operation.  In
Ada 95 and CLOS (Common Lisp Object System), this object is identified
as one of the parameters of the invocation of the operation.

It turns out that the Ada 95/CLOS approach is somewhat more powerful,
in that you can syntactically transform the C++/Smalltalk "prefix"
notation into the Ada 95/CLOS "parameter" notation, but not necessarily
vice-versa.  Both Ada 95 and CLOS allow multiple "objects" controlling
the dispatch, making binary operations simpler and more symmetrical.
Ada 95 is unique in allowing the result context to control the run-time 
dispatch.  CLOS is more general in that a best-fit pattern match is performed
at run-time to decide which implementation to invoke (roughly analogous
to the best-fit compile-time overload resolution algorithm that 
C++ performs), while Ada 95 requires a "perfect" match (allowing a simple
single-level-of-indirection to perform the dispatch).

So when you see "object->operation(other params)" in C++ or
"object op other-params" in Smalltalk, you can imagine
this as "operation(object, other params)" in Ada 95 (or 
"(operation object other-params)" in CLOS).  When implementing
an operation in Ada 95, the implicit "this" parameter in C++
becomes a normal "formal" parameter in Ada, with a name picked by
the programmer (the programmer could chose "This" if desired).

Although there are some semantic implications of this choice of prefix
vs. parameter notations, by and large it is a syntactic choice.

-Tucker Taft   stt@inmet.com
Intermetrics, Inc.

calling syntax (was Re: Ada Objects)

[Robb Nebbe]

In article <3flk3r$8qj@gdls.com>, wilkinso@gdls.com (Robert M. Wilkinson) writes:
|> In article <D2H5un.FEr@nntpa.cb.att.com>,
|> Kenneth Almquist <ka@socrates.hr.att.com> wrote:
|> >
|> >C++ has two procedure calling syntaxes.  It is possible to write either
|> >   display(myptr);
|> >or
|> >   myptr->display();
|>  
|> Please note that these have *entirely* different semantics; they are not
|> merely "two forms of syntax" for the same thing. 
|>  

I'm not sure you would want to call this a semantic difference. The
semantics are the operation display is called with the parameter
myptr in both cases. The real difference is in the implementation. The
first is just a normal function call like you would find in C (or Ada)
in the second the parameter is called "this" inside the function
and if it is virtual (and the compiler can't be sure exactly what the
pointer points at) then the implementation will be chosen at run-time,
otherwise it is called just like a normal function.

Robb Nebbe

Re: Ada Objects Help!

[Robb Nebbe]

In article <1995Jan20.134150@hobbit>, hathawa2@marshall.edu (Mark S. Hathaway) writes:


|> Then the Ada example changes 'myclass(int)' to 'Create(X : Integer) return T'
|> with the added complexity of defining T.  It looks wrong or overly complex.
|> And it's comparable in length to the C++ version only because the class
|> implementation isn't given.

Ada doesn't have constructors so a function returning the type is what
you would use. Defining T isn't any more complex it is just longer. Ada
provides a more general approach by separating types and modules. To
get the same level of generality C++ has nested classes.

|> Does the Ada example even create an object?

Yes, but not on the heap.

|> Here's my idea of how it should look.

(example deleted) I don't see any big difference. You have a complete
separation of implementation and interface but that implies that you
are going to work with more levels of indirection or you are going
to perform what is often considered as code generation at link time.

There are many aspects of both Ada and C++ that are in the language not
so much because they are the best way to do it from some theroretical
perspecitve but because of practical reasons such as "what do
compiler writers know how to do well?" and "what do operating systems
currently support?"

Robb Nebbe

Re: Ada Objects Help!

[Stephane Barbey]

From barbey Mon Jan 23 11:51:37 1995
Date: Mon, 23 Jan 95 11:51:34 +0100
From: barbey (Stephane Barbey)
To: hathawa2@marshall.edu (Mark S. Hathaway)
Cc: Stephane.Barbey
Subject: Re: Ada Objects  Help!

In article <1995Jan20.134150@hobbit>, you write:
: > In article <1995Jan16.132400@lglsun.epfl.ch>,
: > nebbe@lglsun.epfl.ch (Robb Nebbe) writes:
: 
: >> In article <3f9g1u$j4m@nps.navy.mil>, swdecato@nps.navy.mil writes:
: 
: >> I wan't to duplicate the following C++ code in Ada.

... but I do not want to duplicate it in this post.


: It's not obvious if 'myclass(int)' is creating a list of objects of type
: myclass or if it's assigning 10 --> dataelement.  It's not very eloquent.

What is obvious is that myclass(int) is a constructor that takes an
integer as a parameter.

: Then the Ada example changes 'myclass(int)' to 'Create(X : Integer) return T'
: with the added complexity of defining T. 

So it is a (member) function that returns an object of type T and takes
an integer as a parameter... It seems to me to be an (almost)
acceptable translation of the C++'s class spec.

: It looks wrong or overly complex.

It isn't wrong. I do not think it is complex either, because the
translation from C++ to Ada 95 is straightforward in this example.

I do not see the complexity in having to define T either. A C++ class
is simultaneously a package and a type, thus the Ada 9X defines a
package and a type. 

I'guess you'll say that it is a lack of unification (See Meyer's seven
sins of OOP), but then, in C++, you find the (strange to me) concept of
having the files (i.e. an OS concept) as a means of modularity, thus
having visibility rules applied to entities defined in the file vs.
other files and visibility rules applied to entities defined in classes
vs. the rest of the world, but the different kind of friends hat have
access to what even your descendants can't see.

Ada has no "bastard unification" between type and class, but unifies
what need to be unified, i.e. packages are the construct to handle
modularity & encapsulation. 

[ObAdvertisement: take a look at my paper in the proceedings of TRI-Ada
94, which handle some of these issues.]


: 
: Here's my idea of how it should look.
: 

[An idea of how it should look in Eiffel++]

: 
: Isn't this closer to what the C++ example is "saying"?
: 

No.

For instance because it is not the same state machine. In your
example, it is possible to call Display between New and Assign, thus it
is possible to try to call Display on an "unitialized" object, which is
not allowed by the C++ spec. Not familiar with oo software testing, are
you?

Note that this is also possible in Rob's spec. (That's why I said that
it was "almost" acceptable.)

My translation would be (by diff'ing Rob's spec):

> package P is  -- Just the specification
>    type T is tagged private;

     type T (<>) is tagged private;
     -- so that no object of T can be created without
     -- initializing it first (here by calling Create).  

>    function Create( X : Integer ) return T;

     function Create (X: Integer) return T'Class;
     -- because in C++, constructor operations are not inherited.
     -- [See my TRI-Ada paper on that point too.] 
      
>    procedure Display( X : T );
> private
>    type T is tagged
>       record
>          Data_Element : Integer;
>       end record;
> end My_Package;

  end P;
  -- to please the compiler.
  

-Stephane

--
Stephane Barbey				"It's not easy getting real wings"	
INJ-335, barbey@di.epfl.ch

Re: ADA Objects Help!

[Robb Nebbe]

In article <3frlje$rpr@gnat.cs.nyu.edu>,
dewar@cs.nyu.edu (Robert Dewar) writes:

|> Mats, if you don't see any problems in package types, then you have
|> not even started to scratch the surface.

Robert, if you think that they are all unresolvable, then you have not
even started to scratch the surface. :-)

Personally, I prefer the approach where packages are not types but I've
read Mats' thesis and I believe he had the basis of a workable solution.
I would guess that what Mats suggested in his thesis is quite a bit
different from what you have imagined in your head.

Robb Nebbe

Re: ADA Objects Help!

[Mats Weber]

In article <3forgl$11cd@watnews1.watson.ibm.com>, ncohen@watson.ibm.com wrote:

> Aren't you glad I wasn't on your thesis review committee? ;-)

No, I think the discussion would have been _interesting_ :-)

Mats

Re: calling syntax (was Re: Ada Objects)

[John DiCamillo]

nebbe@lglsun.epfl.ch (Robb Nebbe) writes:

>In article <3flk3r$8qj@gdls.com>, wilkinso@gdls.com (Robert M. Wilkinson) writes:
>|> In article <D2H5un.FEr@nntpa.cb.att.com>,
>|> Kenneth Almquist <ka@socrates.hr.att.com> wrote:
>|> >
>|> >C++ has two procedure calling syntaxes.  It is possible to write either
>|> >   display(myptr);
>|> >or
>|> >   myptr->display();
>|>  
>|> Please note that these have *entirely* different semantics; they are not
>|> merely "two forms of syntax" for the same thing. 
>|>  

>I'm not sure you would want to call this a semantic difference. The
>semantics are the operation display is called with the parameter
>myptr in both cases.

The semantic difference is not in the calling sequence, but
in the display operation itself.  The member function display
has access to the internals of the class; the global function
display does not.

It seems to me (I'm no expert) that Ada95 does not need (or
provide) the member function concept because Ada separates
the notions of type and visibility.

>The real difference is in the implementation. The
>first is just a normal function call like you would find in C (or Ada)
>in the second the parameter is called "this" inside the function
>and if it is virtual (and the compiler can't be sure exactly what the
>pointer points at) then the implementation will be chosen at run-time,
>otherwise it is called just like a normal function.

All correct.  (Of course, Ada95 provides dynamic dispatch
as well, it just uses similar syntax as for static dispatch.)

-- 
    ciao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: ADA Objects Help!

[Ed Osinski]

In article <3flk3r$8qj@gdls.com>, wilkinso@gdls.com (Robert M. Wilkinson) writes:
|> In article <D2H5un.FEr@nntpa.cb.att.com>,
|> Kenneth Almquist <ka@socrates.hr.att.com> wrote:
|> >
|> >C++ has two procedure calling syntaxes.  It is possible to write either
|> >   display(myptr);
|> >or
|> >   myptr->display();
|>  
|> Please note that these have *entirely* different semantics; they are not
|> merely "two forms of syntax" for the same thing. 
|>  
|> >These both call a procedure, passing the value myptr as the argument.
|> >In contrast, Ada provides only a single procedure call syntax.
|> >
|> >When you declare a procedure in C++ you specify which syntax will be
|> >used to call the procedure.
|>  
|> Again, there is much more to it than just the syntax.  One is a member
|> function, the other is a plain-old function.  Big, big, difference. 

Sure, but why does the caller need to know which one is used?

|> >As a result, having the two syntaxes
|> >provides the following functionality:
|> >
|> >1.  Both Ada and C++ provide overloading, but in C++ it is possible for
|> >    two overloaded routines to have the same argument types as long as
|> >    the calling syntax is different.  The two calls to "display" which
|> >    appear above call different routines.
|>  
|> Of course they do.  One calls a member function, the other does not.  Think
|> of it as calling two functions with the same signature, but residing in
|> different packages.  
   ...
|> >My own opinion, formed before I knew anything about Ada 9X, is that this
|> >functionality is not useful, and thus having two syntaxes increases the
|> >complexity of the language without providing any corresponding benefit.
|>  
|> Perhaps you need a better C++ book.  If you cannot see the need for 
|> member functions, which is the heart and soul of C++, then you definitely
|> do not understand the language. 

But that is *not* what Kenneth said.  He simply doesn't see the need for two
different syntaxes.  Let me give you an example.  In C++, the *same* syntax is
used to call a virtual member function and a non-virtual member function.  Is a
virtual member function different from a non-virtual one in semantics?  Of
course they are, but that does not mean that there must be a different syntax
for calling them.  In fact, even C++ does let you use the non-member syntax for
*some* members.  They're called operators.  When you see

	a + b

and a and b are values of some user-defined type, the '+' could be a member
function, or a non-member function, but the syntax to invoke either is
identical.  Ada95 has one consistent syntax for calling both member functions
(or their nearest equivalent) and non-member functions.  This doesn't seem to
cause any problems.

|> -- 
|> ____________________________________________________________________________
|>   
|> Rob Wilkinson                                              wilkinso@gdls.com
|> ____________________________________________________________________________

-- 
---------------------------------------------------------------------
 Ed Osinski                  |
 Computer Science Department | "Do I know you? 
 New York University         |  And don't try to deny it!"
 E-mail:  osinski@cs.nyu.edu |                 Col. Flagg to Hawkeye
---------------------------------------------------------------------

Re: Ada Objects Help!

[Jacob Sparre Andersen]

Tucker Taft (stt@henning.camb.inmet.com) wrote:
|^^^^^^^^^^
| As Robert is implying, object-oriented languages differ in both significant
| and insignificant ways.  Clearly you need to identify the object which
| is the "target" when invoking an operation.  In C++ and Smalltalk, this object
| is identified in a "prefix" of the invocation of the operation.  In
| Ada 95 and CLOS (Common Lisp Object System), this object is identified
| as one of the parameters of the invocation of the operation.
|
| It turns out that the Ada 95/CLOS approach is somewhat more powerful,
| in that you can syntactically transform the C++/Smalltalk "prefix"
| notation into the Ada 95/CLOS "parameter" notation, but not necessarily
| vice-versa.  Both Ada 95 and CLOS allow multiple "objects" controlling
| the dispatch, making binary operations simpler and more symmetrical.
| Ada 95 is unique in allowing the result context to control the run-time 
| dispatch.  CLOS is more general in that a best-fit pattern match is performed
| at run-time to decide which implementation to invoke (roughly analogous
| to the best-fit compile-time overload resolution algorithm that 
| C++ performs), while Ada 95 requires a "perfect" match (allowing a simple
| single-level-of-indirection to perform the dispatch).
 ^^^^^^^^^^
I am pretty sure I know how Borland Pascal and C++ decides which virtual 
method to call, but as I've understood Ada95, the decision could be based on 
more than one object. Am I right? And how is it done?

Regards,
                Jacob Sparre Andersen
--
A good movie? - What about three? - Kieslowskis 'White', 'Blue' and 'Red'!
--
URL's: "mailto:sparre@nbi.dk", "http://meyer.fys.ku.dk/~sparre", 
       "mailto:sparre+@pitt.edu" & "http://www.pitt.edu/~sparre".
--
"We need a plan to diverge from", Fesser

Re: ADA Objects Help!

[Norman H. Cohen]

In C++, members may be static or nonstatic and may be data members or
function members: 

   class C {
      public: 
         int nonstatic_data_member;
         static int static_data_member;
         void nonstatic_function_member(int x);
         static void static_function_member(int x);
   };

   static void C::nonstatic_function_member(int x) {
      [references to static_data_member or nonstatic_data_member]
   }

   static void C::static_function_member(int x) {
      [references to static_data_member, but not nonstatic_data_member]
   }

These reflect the unified/confused role of a class as a type definition
and as a module.  The equivalent in Ada is: 

   package C_Module is

      type C_Type is
         record
            Nonstatic_Data_Member: Integer;
         end record;

      Static_Data_Member: Integer;

      procedure Nonstatic_Function_Member
         (This: access C_Type; X: in Integer);

      procedure Static_Function_Member (X: in Integer);

   end C_Module;

   package body C_Module is

      procedure Nonstatic_Function_Member
         (This: access C_Type; X: in Integer) is
         ...
      begin
         [references to Static_Data_Member or This.Nonstatic_Data_Member]
      end Nonstatic_Function_Member;

      procedure Static_Function_Member (X: in Integer) is
         ...
      begin
         [references to Static_Data_Member]
      end Static_Function_Member;

   end C_Module;

The Ada formulation is actually a more accurate depiction of the usual
C++ implementation than is the C++ formulation.  The C++ formulation
suggests that each object of class C has space set aside for its own copy
of the function, or at least of a pointer to the function.  (This effect
can be achieved in Ada with a record component belonging to an
access-to-subprogram type.)  In reality, since the function is not
virtual, the function body is the same for all members of the class, so
there is only one copy of it and it is called directly, without going
through any pointers.  A pointer to the object "containing" the called
function is passed to this single copy through the implicit parameter
"this", and a reference to nonstatic_function_member in the function body
is just a shorthand for this->nonstatic_function_member.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: ADA Objects Help!

[swdecato]

I started this discussion on the comp.lang.ada news group and was pleasantly
surprised to see that it had migrated here...

I am a new Ada student, so correct me if I make any glaring mistakes.  Your
sample code attempts to mimic a C++ class using a package.  The problem with
the package implementation is that I can't instantiate instances of the object
at run time.  In Ada, a pointer to a package is created at compile time since
the declaration using the "new" operation occurs prior to the firt BEGIN.  From
a syntax standpoint, Ada packages are as close to C++ classes as you can get,
minus the dynamic allocation.

Many Ada folks have demonstrated how Ada objects are created and deleted.
My argument against the Ada style was that I felt that the C++ syntax more
accurately modelled the englist language.  I have no doubt that the same effect
can be achieved with either language.  I still say that the following code is
easier to understand when dealing with objects...

		MY_TYPE *objectPtr = new MY_TYPE;
                     objectPtr->run();
                     objectPtr->sleep();
		objectPtr->move();		
		objectPtr->Set(A,B);

		etc

In Ada the same program would be:

		Run(objectPtr);
		Sleep(objectPtr);
		Move(objectPtr);
		Set(objectPtr, A, B);

I don't see how passing "structs" to static functions differs from any other
function which takes a parameter.  In my mind, when I create a pointer to 
an object of some user defined class, that one pointer takes any public
data and functions associated with the class. 



		

Re: ADA Objects Help!

[David O'Brien]

Ed Osinski (osinski@hellgate.cs.nyu.edu) wrote:
: |> >
: |> >C++ has two procedure calling syntaxes.  It is possible to write either
: |> >   display(myptr);
: |> >or
: |> >   myptr->display();
: |>  
: |> >These both call a procedure, passing the value myptr as the argument.
: |> >In contrast, Ada provides only a single procedure call syntax.
: |> >
: |> >When you declare a procedure in C++ you specify which syntax will be
: |> >used to call the procedure.
: |>  
: |> Again, there is much more to it than just the syntax.  One is a member
: |> function, the other is a plain-old function.  Big, big, difference. 

: Sure, but why does the caller need to know which one is used?

Point is, you don't.  The first form really won't exist in OOP.  Problem
is both Ada and C++ are hybrid OO languages.  So we keep thinking in
our old imperative way, while trying to implement in an OOP way.

I'm kinda surprised to see this actually since in Ada it is common to
see "text_io.put_line( .... );".  So why does the programmer have to
know which package ``put_line'' belongs to?  Yes we could just "use" the
package, but then you've never worked on a DoD contract that forbidden
the use of "use" statements.  Actually, it is this syntax and scoping
rules that gave Ada83 a partially OO feel.  Plus, it is
self-documenting code.  :-)))

: for calling them.  In fact, even C++ does let you use the non-member syntax 
: for *some* members.  They're called operators.  When you see

: 	a + b

Same syntax as Ada83.  You could use package_name.op( a, b );

-- David O'Brien	(dobrien@seas.gwu.edu)

Re: ADA Objects Help!

[mat]

In article <3fu6qc$pc5@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) writes:
> Rob Wilkinson, if you cannot see that from a purely semantic point of view
> there is nothing particularly special about member functions, then maybe
> it is you who need a better C++ book.

I think that it is you who needs the better book.  See section 4.4.4 of
my _Practical C++_.

> You are viewing them through a semantic filter which says that you will
> view these member functions in a special way, corresponding to a particular
> paradigm that you (and the language design!) have in mind. However, if you
> can manage to take a more basic viewpoint, you will see that member functions
> are just functions, nothing more and nothing less. THey have a special
> syntax and visibility, but that does not mean they are semantically
> fundamentally different from ordinary functions.

They are different.

When parameters are matched, conversions at not applied to the implicit
operand (the object on behalf of which the function is called).
Inheritance is given special treatment.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
	(Training and consulting in C, C++, UNIX, etc.)

Re: ADA Objects Help!

[Bob Kitzberger]

swdecato@nps.navy.mil wrote:

: In Ada the same program would be:
:
: 		Run(objectPtr);
: 		Sleep(objectPtr);
: 		Move(objectPtr);
: 		Set(objectPtr, A, B);

May I suggest an idiom that works better?  First, rid yourself of the
concept of "pointers" and "structs" when dealing with object-based Ada.
This may matter in the class implementation (package body), but clients
should be oblivious.

Second, name the package after the class you are modeling.  The package
package should export a type of that class (around here we just use
the identifier "Object", and often add some sort of "Object_Collection" type
if we want to export a list/set/map/whatever without having to create
a new package)

Third, use fully qualified names:

        My_Mower : Lawnmower.Object := Lawnmower.Create( Lawnmower.Toro );
        begin
            Robot_Arm.Run( My_Mower );
	    Robot_Arm.Sleep( My_Mower );
            Robot_Arm.Move( My_Mower );
            Robot_Arm.Destroy( My_Mower );
        end;


If Lawnmower.Object is dynamically allocated, then that is hidden in
in Create and Destroy (this is Ada83...)

One trap in learning a new language is to try to apply old idioms to the
new language; asking around on Usenet is a great way to find idioms
specific to the language.

	.Bob.

--
Bob Kitzberger	        +1 (916) 274-3075	        rlk@rational.com
Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945
     "Though the boys throw stones at frogs in sport, yet the frogs 
       do not die in sport but in earnest."      - Plutarch

Re: ADA Objects Help!

[Bob Kitzberger]

In a previous note I spewed forth:

:         My_Mower : Lawnmower.Object := Lawnmower.Create( Lawnmower.Toro );
:         begin
:             Robot_Arm.Run( My_Mower );
: 	      Robot_Arm.Sleep( My_Mower );
:             Robot_Arm.Move( My_Mower );
:             Robot_Arm.Destroy( My_Mower );
:         end;

I erred; it's probably obvious, but replace "Robot_Arm" with "Lawnmower".

	.Bob.



--
Bob Kitzberger	        +1 (916) 274-3075	        rlk@rational.com
Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945
     "Though the boys throw stones at frogs in sport, yet the frogs 
       do not die in sport but in earnest."      - Plutarch

Re: ADA Objects Help!

[Mats Weber]

In article <3frlje$rpr@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) wrote:

> Mats, if you don't see any problems in package types, then you have not even
> started to scratch the surface. I don't know if there are any easily
> accessible written discussions of this issue or not. The amount of
> discussion that has occurred on this issue would certainly fill many books.
> It would be helpful to have a summary so that people don't keep rewalking
> the same path without knowing where it leads, but I certainly don't have
> time to do it!

If you have any pointers to litterature on the subject, I am interested.
In the meantime, you may want to have a look at my thesis, which contains
a fairly complete proposal for OO Ada based on package types. Just drop me
a note and I'll send you a PostScript file.

Mats

Re: ADA Objects Help!

[Mats Weber]

In article <1995Jan23.124811@lglsun.epfl.ch>, nebbe@lglsun.epfl.ch (Robb
Nebbe) wrote:

> In article <3frlje$rpr@gnat.cs.nyu.edu>,
> dewar@cs.nyu.edu (Robert Dewar) writes:
> 
> |> Mats, if you don't see any problems in package types, then you have
> |> not even started to scratch the surface.
> 
> Robert, if you think that they are all unresolvable, then you have not
> even started to scratch the surface. :-)
> 
> Personally, I prefer the approach where packages are not types but I've
> read Mats' thesis and I believe he had the basis of a workable solution.
> I would guess that what Mats suggested in his thesis is quite a bit
> different from what you have imagined in your head.

Thanks Robb. Having to face Robert and Norman alone was getting kind of
tough :-).

Re: ADA Objects Help!

[Mats Weber]

In the rest of this message, I assume that type and exception declarations
are not allowed in the visible part of package types.

In article <3forgl$11cd@watnews1.watson.ibm.com>, ncohen@watson.ibm.com wrote:

> In article <Mats.Weber-1901951739360001@mlma11.matrix.ch>,
> Mats.Weber@matrix.ch (Mats Weber) writes: 
> 
> |> In article <3fhggr$11dp@watnews1.watson.ibm.com>,
ncohen@watson.ibm.com wrote: 
> |>
> |> > Because, unlike task units, package units export declarations for use
> |> > outside.
> |>
> |> Well, tasks export entries, which are usable outside just like subprograms
> |> exported from packages.
> 
> True enough.  The entries are per-type entities, whose declarations are
> elaborated once for each task type.  (This is noticeable by the fact that
> entry-family discrete ranges are elaborated once per task type, not once
> for each object of the type.) Entities declared in the declarative part
> of the task body are per-object entities, whose declarations are
> elaborated once per object.

The same rules can be adopted for package types (it's probably the only
reasonable choice anyway).

> The distinction I was trying to make (alhtough I wasn't very clear about
> it) was about per-object entities: The entities declared in a package-
> type declaration would be exported by each object in the package type,
> unlike the per-object entities of a task type.

I must be missing something here. I see entries as belonging to task
_objects_, not task _types_. If you write

   procedure P renames T.E;

then P denotes the E entry of the task _object_ T. Moreover, you cannot
refer to an entry of a task type directly. You need a task object.

> |> >    package type PT is  -- THIS IS NOT VALID ADA XX for XX <= 95 !!!!!!
> |> >       N: Integer := [some nonstatic expression];
> |> >       type T is array (1 .. N) of Integer;
> |> >    end PT;
> |> >
> |> >    Package_1, Package_2: PT;
> |>
> |> The declaration for N does not cause a problem. It would be treated just
> |> like a record component declaration with a default initial value (i.e. the
> |> nonstatic expression is evaluated at each elaboration of a PT).
> 
> This is beginning to look suspiciously like a generic package.  Generic
> templates are the only program units in Ada with the property that
> declarations inside the program-unit declaration are not elaborated as
> part of the elaboration of the program-unit declaration.

To me it looks more like a record type than like a generic package.
Declarations inside the visible part are elaborated at the type
declaration, but not the default initial values, just like for records.
Example:

   package type T is   -- not legal Ada
      N : Integer range 0 .. Max := Initial;
   end T;

is almost equivalent to

   type T is
      record
         N : Integer range 0 .. Max := Initial;
      end record;

I could have written the proposal in my thesis using record types and
allowing procedures as record components (like in N. Cohen's paper), but I
wanted a construct that could express ADTs in a very similar way whether
that ADT was concurrent or not. (I also wanted to be able to export
generic subprograms from my package types, for reasons I won't explain
here). Thus package types and task types.

Another solution preserving the symmetry would be record types + a change
in syntax for task types:

   type T is
      task
         entry A;
      end task;

which would remove the dissymmetry between Ada's task types and other
types. But these considerations are purely syntactical and of limited
interest.

> The term package type is beginning to look like a misnomer.  The
> instances of these types are far more restricted than packages are.
> In fact they are even more restricted than generic packages.
> A package that cannot provide types is little more than a record.

This is a matter of taste, I guess. One similar thing I don't like in Ada
is that a task cannot be a library unit.

Mats

Re: ADA Objects Help!

[swdecato]

I started the ADA Objects Help! discussion in hopes to better understand the
language based since I have only C++ as a reference.  The amount of response
I received was overwhelming and I've collected quite a library for my Ada
notebook.  

I couldn't find a book on the subject, but the discussions here have more than
clarified my questions.  I'm can't wait to apply what I've learned to my next
programming project.

Even though the issue may have been "beaten" in the past, many of us are
new to the Internet or new to Ada.  This is a great place to learn!

Thanks again...

Re: ADA Objects Help!

[Norman H. Cohen]

In article <3g49bu$7fv@nps.navy.mil>, swdecato@nps.navy.mil writes: 

|> I am a new Ada student, so correct me if I make any glaring mistakes.  Your
|> sample code attempts to mimic a C++ class using a package.  The problem with
|> the package implementation is that I can't instantiate instances of the object
|> at run time.

Of course you can: 

   X: C_Type;
   Y: C_Type;
   type C_Pointer_Type is access C_Type;
   Z: C_Pointer_Type := new C_Type;

(C++ confuses things enough by using the same construct, the class, both
as a type definition and a module.  Let's not make it worse by using the
term "object" as a synonym for "class".  An object is an instance of a
class.  In a language in which classes are not runtime entities--in
contrast to Smalltalk, for example--an "instance of an object" is sloppy
and misleading terminology.)

X, Y, and Z.all each contain their own copies of all data that differ
from one object to another.  All the entities that are really the same
for all objects--functions and what C++ calls static data--are declared
in the package, clearly indicating that they are per-type (or
per-package, or per-class) entities rather than per-object entities.

|>               In Ada, a pointer to a package is created at compile time since
|> the declaration using the "new" operation occurs prior to the firt BEGIN.  From
|> a syntax standpoint, Ada packages are as close to C++ classes as you can get,
|> minus the dynamic allocation.

Ada packages are not run-time entities, any more than a C header file is.
They are a mechanism for grouping logically related entities.  They are
not assigned, pointed to, or passed to subprograms.  They are not
components of arrays or records.  A package IS analogous to a class in
that both can be used as modules.  A record-type declaration is analogous
to a class in that both can contain components and have instances of
them, each of which has its own copies of each of the components.

|> Many Ada folks have demonstrated how Ada objects are created and deleted.
|> My argument against the Ada style was that I felt that the C++ syntax more
|> accurately modelled the englist language.  I have no doubt that the same effect
|> can be achieved with either language.  I still say that the following code is
|> easier to understand when dealing with objects...
|>
|>              MY_TYPE *objectPtr = new MY_TYPE;
|>                      objectPtr->run();
|>                      objectPtr->sleep();
|>              objectPtr->move();
|>              objectPtr->Set(A,B);
|>
|>              etc
|>
|> In Ada the same program would be: 
|>
|>              Run(objectPtr);
|>              Sleep(objectPtr);
|>              Move(objectPtr);
|>              Set(objectPtr, A, B);

There is a style of Ada programming that reminds you which package is the
source of the operations you are calling: 

   package Widgets is
      type Widget_Type is ...;
      type Widget_Pointer_Type is access Widget_Type;
      procedure Run (X: access Widget_Type);
      procedure Sleep (X: access Widget_Type);
      procedure Move (X: access Widget_Type);
      procedure Set (X: access Widget_Type; Y, Z: in out Who_Knows_What);
      ...
   end Widgets;

   Object_Pointer : Widgets.Widget_Pointer_Type := new Widget_Type;
   A, B           : Who_Knows_What;
   ...
   Widgets.Run (Object_Pointer);
   Widgets.Sleep (Object_Pointer);
   Widgets.Move (Object_Pointer);
   Widgets.Set (Object_Pointer, A, B);

Some Ada programmers feel that the code is easier to understand with the
dotted notation and some do not.  This is the "use clause controversy": 
Without a use clause, you are forced to use the dotted notation.  Some
Ada programmers feel that there is no one approach that is always best,
but that it depends on a number of factors, such as whether Widgets is a
well-known package whose facilities will be instantly recognized by all
programmers, whether lots of different facilities from lots of different
packages are all being used in the same place, whether the facilities
provided by the package have descriptive names, whether there are
name clashes among several packages being used in the same place, and
what kind of tools, from cross-reference listings to hypertext links, are
available to tell the program reader where any undotted names come from.

|> I don't see how passing "structs" to static functions differs from any other
|> function which takes a parameter.  In my mind, when I create a pointer to
|> an object of some user defined class, that one pointer takes any public
|> data and functions associated with the class.

You are certainly not alone in that respect, but I do not find it helpful
to create the fiction that a one-per-package subprogram or variable is
somehow "included" in all objects of a type declared in a package, and
pointed to by all pointers to objects of that type (especially since, on
occasion, it is most appropriate for the same package to provide more
than one type).

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Ada Objects Help!

[Robert A Duff]

In article <1995Jan24.230910.2241@nbivax.nbi.dk>,
Jacob Sparre Andersen <sparre@meyer.fys.ku.dk> wrote:
>I am pretty sure I know how Borland Pascal and C++ decides which virtual 
>method to call, but as I've understood Ada95, the decision could be based on 
>more than one object. Am I right? And how is it done?

Yes, it is possible for more than one parameter to be "controlling".  In
that case, there's a run time check that the tags of all controlling
parameters are equal.  If they are, then that tag determines what
subprogram body to dispatch to.

It's not like CLOS, which has "multi-methods", which can dispatch based
more than one parameter, according to a rather complicated set of rules.

By the way, dispatching on result is an interesting twist that most OOP
languages don't have:

    function Union(X, Y: Set) return Set;
    function Empty_Set return Set;

    X: Set'Class := ...;
    Y: Set'Class := Union(X, Empty_Set);

The appropriate version of function Empty_Set to call is determined (at
run time) based on the tag of Y, since Empty_Set itself doesn't have any
controlling parameters.

- Bob

Re: ADA Objects Help!

[Robert Dewar]

Mats, since there seem to be quite a few people interested in this, can you
perhaps put the PS of your thesis in an FTP area where people who are
interested in getting it can ...

Re: ADA Objects Help!

[Robert Dewar]

Interesting, that's certainly a drastic restriction (stopping package types
from exporting types and exceptions), and to my mind breaks the abstrction
of a package (after all defining a procedure without being able to define
its associated types seems unfortunate).

Still I will wait to read the thesis. Certainly if you restrict packages
enough they can be types (if you restrict them enough, they are simply
records :-)

Re: Ada Objects Help!

[Robert A Duff]

In article <D30tDn.41x@world.std.com>, I wrote:
>    X: Set'Class := ...;
>    Y: Set'Class := Union(X, Empty_Set);
>
>The appropriate version of function Empty_Set to call is determined (at
>run time) based on the tag of Y, since Empty_Set itself doesn't have any
>controlling parameters.

I meant "based on the tag of X".  Sorry if I confused anyone.

(Thanks, Stephane and Anthony, for pointing this out.)

- Bob

Re: Ada Objects Help!

[Tucker Taft]

In article <D30tDn.41x@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
> ...
>By the way, dispatching on result is an interesting twist that most OOP
>languages don't have:
>
>    function Union(X, Y: Set) return Set;
>    function Empty_Set return Set;
>
>    X: Set'Class := ...;
>    Y: Set'Class := Union(X, Empty_Set);

>The appropriate version of function Empty_Set to call is determined (at
>run time) based on the tag of Y, since Empty_Set itself doesn't have any
                               ^^ "X"
>controlling parameters.

Although I presume Bob meant "X" in the above paragraph,
you actually *can* use the left-hand side of an assignment statement
(rather than an initialization) to control the dispatching.  
For example, presuming Y was declared as above, we can later 
assign into Y again as follows:

    Y := Union(Empty_Set, Empty_Set); 

In this example, Y is the only thing with a pre-determined tag, and it 
controls all dispatching.

>- Bob

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: ADA Objects Help!

[John DiCamillo]

ka@socrates.hr.att.com (Kenneth Almquist) writes:
>swdecato@cs.nps.navy.mil wrote:
>> Many Ada folks have demonstrated how Ada objects are created and deleted.
>> My argument against the Ada style was that I felt that the C++ syntax more
>> accurately modelled the englist language.

>I don't know about you, but when I issue a command in English I place the
>verb before the noun, as in "Mow the lawn."  This translates naturally to
>the C or Ada code:

>	mow(lawn);

>The C++ alternative,

>	lawn->mow();

>is backwards.

Actually, your example is backwards.  An imperative in English has
an implicit subject (usually 'you', that is, the person being commanded)
and an explicit object (in this case, 'lawn').  So the Ada code would
be:

  mow(robot, lawn);

and the C++ would be:

  robot.mow(lawn);

>Not to make too big a deal about this--either order (noun before verb or
>verb before noun) is readable once you get used to it.  I doubt that one
>order is inherently "better" than the other. 

Agreed.

>However, using both orders
>in the same program seems like a bad idea if you are concerned about
>readability.

Oh, no.  Here I must disagree.  The two syntaxes (in C++) represent
operations with different properties, so having a single syntax is
potentially confusing.  Note:  I don't believe that the amount of
confusion in either case is significant, but I am satisfied with the
C++ (and Eiffel, and Smalltalk, and...) syntax.

>				Kenneth Almquist
-- 
    ciao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: ADA Objects Help!

[mat]

In article <D330pK.M1@nntpa.cb.att.com>, ka@socrates.hr.att.com (Kenneth Almquist) writes:
> swdecato@cs.nps.navy.mil wrote:

> I don't know about you, but when I issue a command in English I place the
> verb before the noun, as in "Mow the lawn."  This translates naturally to
> the C or Ada code:
> 
> 	mow(lawn);
> 
> The C++ alternative,
> 
> 	lawn->mow();
> 
> is backwards.
> 
> Not to make too big a deal about this--either order (noun before verb or
> verb before noun) is readable once you get used to it.  ...

When something seems backwards, often it is.  What you really mean is

	lawn->be_thou_mowd();

Now, is this part of the interface provided for a lawn mower to access?
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
	(Training and consulting in C, C++, UNIX, etc.)

Re: ADA Objects Help!

[David Emery]

>Actually, your example is backwards.  An imperative in English has
>an implicit subject (usually 'you', that is, the person being commanded)
>and an explicit object (in this case, 'lawn').  So the Ada code would
>be:
>  mow(robot, lawn);
>and the C++ would be:
>  robot.mow(lawn);

In this example, the 'robot' is an active entity.  Therefore the
"appropriate" Ada abstraction is:
	task robot is
	  entry Mow (location : large_grassy_space);
	end robot;
and we end up with (surprise!):
	robot.mow (lawn);

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Subject/Object Confusion Syndrome [was: Ada Objects Help]

[John Volan]

milod@netcom.com (John DiCamillo) writes:

>ka@socrates.hr.att.com (Kenneth Almquist) writes:
>>swdecato@cs.nps.navy.mil wrote:
>>> Many Ada folks have demonstrated how Ada objects are created and deleted.
>>> My argument against the Ada style was that I felt that the C++ syntax more
>>> accurately modelled the englist language.
>>
>>I don't know about you, but when I issue a command in English I place the
>>verb before the noun, as in "Mow the lawn."  This translates naturally to
>>the C or Ada code:
>>
>>	mow(lawn);
>>
>>The C++ alternative,
>>
>>	lawn->mow();
>>
>>is backwards.
>
>Actually, your example is backwards.  An imperative in English has
>an implicit subject (usually 'you', that is, the person being commanded)
>and an explicit object (in this case, 'lawn').  So the Ada code would
>be:
>
>  mow(robot, lawn);
>
>and the C++ would be:
>
>  robot.mow(lawn);
>

Actually, in the first C++ example, I'd say that the lawn is the
*subject* of the command, not the *object*!  The trouble here is that,
although C++ is deemed to be "object-oriented" -- it implements inheritance,
polymorphism, dynamic binding, etc. -- nevertheless, its method-calling
syntax is really *subject* oriented!  Let me explain:

If you want to interpret a C++ member-function call such as

	lawn->mow();

as an English imperative sentence, you really have to translate it as:

	"Hey, Mr. Lawn! Go mow yourself! (Uh, no offense. :-)
	(Oh, by the way, mow yourself in whatever fashion is
	appropriate for whatever type of lawn you are.)"

As whimsical and anthropomorphic as this sounds, I seriously believe
that this represents the kind of mindset you need to adopt in order to
program effectively in any language that uses this kind of syntax --
e.g., C++, Smalltalk, Eiffel, etc.  The fact that this sort of thing
sounds so whimsical and counter-intuitive is, in my view, a serious
problem, something which I call "Subject/Object Confusion Syndrome."
The ironic thing is that this confusion only arises because of a
choice of *programming language* syntax, yet, in my experience, it's
resulted no end of difficulties for engineers trying to grasp the
concepts of object-oriented *design*.

Every computer program has responsibilities to perform certain actions
and computations with respect to the "objects" in its problem domain.
A good object-oriented design will take all the responsibilities that
pertain to a given class of real-world objects and encapsulate them
into a single, cohesive software module.  But in order to render that
into a programming language that uses this "subject-oriented" syntax,
you have to imagine that the objects *themselves* are responsible for
the actions that the computer has to "do" to them.  Now, we all know
that it's really the *computer* that's going to "do" these things --
in other words, the computer is really the "subject" of our program's
imperative commands.  However, because of the syntax involved, you
have to pretend that it's actually the "objects" that are the
"subjects" of these commands.

In the example above, we know that we're really telling the computer
to invoke the "mow" function, and the "lawn" object is really an
implied parameter to this function (passed in through the so-called
"this" pointer).  This parameter has some special semantics -- its
run-time type information is used to dynamically dispatch to the
appropriate implementation of "mow" -- but it's still just a
parameter.  However, because of the syntax of the call, we're left
with the impression that it's the lawn that is the subject that is
doing the mowing.

In my experience, this confusion between "subject" and "object" is the
single most difficult conceptual hurdle you have to overcome in order
to master the object-oriented paradigm, whenever you work in languages
like C++ or Smalltalk.  Because of this confusion, it can be difficult
at times to decide where a certain responsibility should go.  For instance,
in deciding which object should have the responsibility to "mow", you 
have to keep remind yourself that the "lawn" object is not really the
"lawn" itself.  It's just the "part-of-the-computer-responsible-for-doing-
things-to-the-lawn" -- including, perhaps, mowing it.  

However, it is very easy to fall into the trap of inventing spurious
"functional" objects, whose only role is to "do" things to your
objects of interest.  For instance, it may seem perfectly reasonable
to argue that lawns don't mow themselves in the real world.  Don't you
need someone or something to actually do the job?   Like, maybe, 
some kind of "robot" object:

>  robot.mow(lawn);

This may sound okay at first: A "robot" object is chunk of software
that knows how to mow a lawn.  When we want a lawn mowed, we'll just
tell a "robot" object to do it.  But in reality this design is
horrible!  The premise was that there are different kinds of lawn that
have to be mowed in different ways.  Does this "robot" object now have
to know about all these different lawn types?  Does it have to do some
kind of switch-statement to discriminate among them?  Or do we now
need to have different classes of robot, one for each type of lawn?
If so, then what's the point of having different lawn classes anyway?
They seem to be just passive data now.  The object-oriented goal of 
encapsulating data and processing together seems to have been lost.

The answer, of course, is that this this "robot" idea just doesn't
work.  The "lawn" object itself is *already* the "thing-that-knows-
how-to-mow-a-lawn."

Contrast this with languages like CLOS or Ada95.  They also implement
inheritance, polymorphism, and dynamic binding, so they are also
deemed "object-oriented."  However, there was no attempt to adopt a
"subject-oriented" method-invoking syntax.  Instead, these languages
took the old, tried-and-true, imperative subprogram-invoking syntax,
and added whatever semantic enhancements were needed in order to
support polymorphic dynamic dispatching.  Consider the Ada95 example:

	Mow (The_Lawn);

Assuming that The_Lawn is a class-wide (polymorphic) tagged-type
variable, this could be translated into an English imperative sentence
as follows:

	"Computer! Go mow the lawn! (Shades of Star Trek? :-)
	(Oh, by the way, mow the lawn in whatever fashion is
	appropriate for whatever class of lawn it is.)"

Here, "the lawn" is the *object* of the sentence -- it is the thing to
which the action of the sentence is directed.  In the corresponding
Ada code, "The_Lawn" is the "object" to which the action of the "Mow"
procedure is directed.  The "subject" perfoming this action is, of
course, the computer itself, just as in every other imperative
programming statement.  In fact, you could view the exclamation 
"Computer!" as an implicit part of every single line of code.

The only difference between this subprogram call and an "ordinary"
subprogram call are semantic differences, not syntactic ones.
"The_Lawn" is a special, polymorphic, "controlling" parameter. It has
a run-time tag that will be used to dynamically dispatch to the
appropriate implementation of Mow.

IMHO, using this traditional imperative syntax is much easier to grasp
than "subject-oriented" syntax.  When used for dynamic dispatching, it
achieves exactly the same semantics as C++'s member-function call.  Yet 
it's much clearer what's "really" going on.  There's no phantom "this"
parameter that you have to know about in order to explain things.

There's still the issue of object-oriented encapsulation:  How do we
convey the fact that the "Mow" procedure is just an integral part of a single
cohesive idea known as the "Lawn" class?  C++ makes it a "member function" of a
class type, with the confusing effect of making it look like a structural
component of every single instance object of that class.  Ada95 uses packaging
to do encapsulation:  We can devote a package to describe the "Lawn" class,
encapsulating within it everything that pertains to lawns, including
an object-oriented (tagged) type and its primitive operations:

	package Lawn is
	  type Object is tagged private;
	  procedure Mow (The_Lawn : in out Lawn.Object);
	  ... other primitive operations ("member functions" in C++)
	private
	  type Object is tagged
	    record
	      ... -- lawn components ("member data" in C++)
	    end record;
	end Lawn;

So, in actuality, a call to the Mow procedure needs to include the package name
as context:

	Lawn.Mow (The_Lawn);  -- assuming The_Lawn is of type Lawn.Object'Class

It's clear that this "Mow" procedure is a modular part of package
Lawn, which encapsulates the *class* of Lawns. "Mow" is *not* a
structural part of The_Lawn *object* that is being passed into it.

Don't confuse this dotted notation with C++'s dotted member notation.
"Lawn.Mow" doesn't mean that "Lawn" is some kind of subject for the
verb "Mow".  The "subject" of the command is still the computer.  If
anything, "Lawn" here could be interpreted as an *adverb* qualifying
the verb "Mow".  All it's indicating is the *scope* in which the Mow
procedure is defined. The closest equivalent to this in C++ is using a
*scope operator*:

	lawn->Lawn::mow();

assuming:

	class Lawn {
	public:
	  void mow ();
	  ... other members
	};

	Lawn lawn;


>>Not to make too big a deal about this--either order (noun before verb or
>>verb before noun) is readable once you get used to it.  I doubt that one
>>order is inherently "better" than the other. 
>
>Agreed.
>
>>However, using both orders
>>in the same program seems like a bad idea if you are concerned about
>>readability.
>
>Oh, no.  Here I must disagree.  The two syntaxes (in C++) represent
>operations with different properties, so having a single syntax is
>potentially confusing.  Note:  I don't believe that the amount of
>confusion in either case is significant, but I am satisfied with the
>C++ (and Eiffel, and Smalltalk, and...) syntax.


I agree that, looking at things mechanically, syntax doesn't really
matter much, because the semantics wind up being the same anyway.  But
I'd say that choice of syntax in a language can have a tremendous
impact on how readily software engineers can internalize good
object-oriented design techniques, without getting confused and
falling into semantic traps.  Sure, if you're a "guru," you can get
used to whimsical things like lawns mowing themselves, or employees
paying themselves their salaries, or enemy missiles engaging and
destroying themselves.  But should every object-oriented software
engineer have to be a "guru" in order to be an effective designer?

Well, that's just some food for thought, I don't really want to start
a language war over this.  Don't mow me down! :-)

				-- John Volan

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Shameless_Controversial_Marketing_Slogan_For_Favorite_Language =>
      "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>" &
      "Inheritance, hierarchical name-space, generic templates, type-safety, " &
      "readability, C/C++/COBOL/FORTRAN interoperability, numeric precision, " &
      "multi-threading, distributed systems, real-time, safety-critical ...  " &
      "<< A d a 9 5  :  Y o u   n a m e   i t ,  i t ' s   i n   t h e r e >>",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

Re: Subject/Object Confusion Syndrome [was: Ada Objects Help]

[Norman H. Cohen]

In article <D38q48.3yM@swlvx2.msd.ray.com>, jgv@swl.msd.ray.com (John Volan)
writes: 

|> Every computer program has responsibilities to perform certain actions
|> and computations with respect to the "objects" in its problem domain.
|> A good object-oriented design will take all the responsibilities that
|> pertain to a given class of real-world objects and encapsulate them
|> into a single, cohesive software module.  But in order to render that
|> into a programming language that uses this "subject-oriented" syntax,
|> you have to imagine that the objects *themselves* are responsible for
|> the actions that the computer has to "do" to them.  Now, we all know
|> that it's really the *computer* that's going to "do" these things --
|> in other words, the computer is really the "subject" of our program's
|> imperative commands.  However, because of the syntax involved, you
|> have to pretend that it's actually the "objects" that are the
|> "subjects" of these commands.
...
|>
|> In my experience, this confusion between "subject" and "object" is the
|> single most difficult conceptual hurdle you have to overcome in order
|> to master the object-oriented paradigm, whenever you work in languages
|> like C++ or Smalltalk.  Because of this confusion, it can be difficult
|> at times to decide where a certain responsibility should go.  For instance,
|> in deciding which object should have the responsibility to "mow", you
|> have to keep remind yourself that the "lawn" object is not really the
|> "lawn" itself.  It's just the "part-of-the-computer-responsible-for-doing-
|> things-to-the-lawn" -- including, perhaps, mowing it.

Thanks for an insightful analysis, which goes right to the heart of the
dispute between advocates of the

   object.operation(...)

and

   operation(object,...)

notations.

While these observations argue against the object.operation(...) notation
in C++, they do not apply to a language like Actors, where objects are
truly active.  Ada tasks are also active objects, and John's discussion
explains the indecision I've often had naming entries of Ada tasks.
Where John thinks in terms of the "computer" having responsibility to
perform certain actions, I think in terms of tasks having those
responsibilities (including the environment task that executes the main
subprogram of a single-task program); I think of procedure calls as
imperatives addressed to a task.  But when a rendezvous is to take place
so that a sender task can notify a recipient task that some event has
taken place, it is not clear whether the entry call should read as an
imperative addressed to the calling task--

 Recipient.Notify_Of_Event; -- Yo, Sender! Notify Recipient of the event!

--or the called task--

 Recipient.Note_Event; -- Yo, Recipient! Note that an event has occurred!

In John's terms, should the task name in an entry call be the subject or
the object?

(By the way, I also think the object.operation(...) notation is
justifiable for a language like Self, where different standalone objects
of the same class can have different methods.  Such methods really are
members, hardly distinguishable from data members.  My objection to the
use of this notation in C++ is that it gives the impression that
different objects in the class each have their own member functions when
in fact they all have the same function.  C++ is pretending to support a
paradigm that it does not support in earnest, the way Self does.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Subject/Object Confusion Syndrome [was: Ada Objects Help]

[Maarten Landzaat]

John Volan writes:

>... excellent stuff on why syntactic sugar IS important.

Not many people seem to share this interest in the influence of syntax
on design, readability and other important things.

When I was learning computer science on the university, I always wondered
why I had to say things like

   Show(Window, 33, 45, over_there, graph);

While I could already envision that

   Show my graph in a standard window at position (33,45).

wouldn't be too hard for a computer to translate, especially if I had told him
before that

   Show (object) (how) at position (x,y)

was about to show up somewhere in the program.

I thought that this was a wonderful idea, but no-one seemed to see the
big difference between the two. 

Still I think that ease of use and understandability can make the difference.
Look at the difference between X400 and internet adresses. Look at the
success of PCs after Windows came out, compared to the preceding MSDOS. 


On the same line:

I once mentioned in comp.lang.ada that I found the keyword 'tagged'
a very confusing and non-intuitive way of expressing object-
orientedness. But nobody seemed to mind. I didn't expect that from
people interested in a thoroughly designed language as Ada.


On "robot.mow(the_lawn)":

To my surprise, many projects I've seen that claim to have object 
oriented designs, have 'objects' like Process_Messages, Initialization,
Sender etc. Terrible! It's OK if designs are like this, but calling
them object-oriented is just another way of saying "I don't know what
OO is, and I don't know the difference between a procedure and a
variable". 

Just some thoughts...

-- 
Maarten Landzaat (gijs@mbase97.xs4all.nl)
Amsterdam, Double bass, Fender Jazz Bass, Atari ST, Roland Sound Canvas.
Listen to M-BASE music!

Re: Subject/Object Confusion Syndrome [was: Ada Objects Help]

[Robb Nebbe]

I took comp.lang.c++ off the distribution list. (If they want to read
interesting posts they can just read comp.lang.ada :-)

In article <D3H7J3.B2x@inmet.camb.inmet.com>, stt@henning.camb.inmet.com (Tucker Taft) writes:
|> 
|> Here is another analogy.  In a normal "dispatching" call, the tag
|> of the controlling parameters determines how the "order" given by
|> the calling task is carried out, but there is no doubt that something
|> will happen.  In a call on a protected object, not only is the
|> interpretation of the call up to the protected object, but whether
|> or not the "order" is carried out at all is up to the protected object.

This doesn't seem quite right. A protected object has no say about which
calls will be executed. It can enforce that it be in a certain state for
a call to take place but this is really no more than a temporal
pre-condition. In contrast a task must explicity accept a call on an
entry and has complete control over such things as the order in which
calls are accepted. A task may also perform actions that are not requested
by someone else, a protected object may not.

I think this is a case where the syntax better represents the
implementation than the semantics. However, I do appreciate that
protected subprograms requiring multiple synchronizations are probably
not "primitve" and is a good enough justification of why the current
syntax was adopted.

|> 
|> Kind of like telling a direct underling to do something, versus
|> "asking" a peer to do something ;-).  "Sorry I'm busy now" is a legitimate
|> answer in the latter case...
|> 

With the cooperative synchronization that exists between tasks this
seems right. I see the competetive synchronization involved with
protected objects as arbitrating the possesion of the object. Thus
multiple peers are competing for the right to tell the protected
object what to do. In John's terminology a protected object can never
be a subject.

Robb Nebbe

Re: Subject/Object Confusion Syndrome [was: Ada Objects Help]

[John Volan]

bsanden@isse.gmu.edu (Bo I. Sanden) writes:

>For anyone interested in the subject-object relationship especially
>w.r.t. Ada tasking, I respectfully submit that I took exactly that 
>tack (including the term "subject") in my book, "Software Systems 
>Construction with Examples in Ada" (Prentice-Hall 1994). 

Interesting ... I honestly haven't run across your book (yet), else I
certainly would have credited you with coining the term for this, er,
subject. :-)

>Bo Sanden
>George Mason University
>Fairfax, Virginia

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

Re: Subject/Object Confusion Syndrome [was: Ada Objects Help]

[John Volan]

dweller@Starbase.NeoSoft.COM (David Weller) writes:
>
>In article <3h1ahp$gf5@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>>
>>You are indeed confused. Tagged does NOT "express object orientedness". It
>>merely says that the type contains a runtime tag allowing type extension and
>>polymorphism.
>>
>
>Quite right.  Much in the same way that templates in C++ are not
>explicitly limited to "generic" situations, considering that
>templates are frequently used to implement bounded arrays in a manner
>that would make Ada people giggle.

Dave, 

You're clearly making a slam against C++, but it sounds like you're
also making a slam against Ada in the same breath.  Now, I do agree
with you that C++'s approach to arrays is inferior to Ada array types.
Although a C++ Array template might imitate Ada's constraint checks,
such a template would constitute "user-defined" code and would not be
intrinsic to the language.  Consequently, I seriously doubt whether
there are any C++ compilers that are savvy enough to optimize accesses
to an array the way Ada compilers typically do -- *without* breaking
the safety that Ada-like arrays provide.  For instance, are there C++
compilers out there that can *remove* index-constraint checks when
they can be proven unnecessary, yet retain them when they are needed?

On the other hand, are you also implying that Ada95 tagged types are
in some way inferior as a means of implementing object-oriented
designs?  If so, what do you mean?

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

Subject/Object Confusion Syndrome [was: Ada Objects Help]

[John Volan]

hathawa2@marshall.edu (Mark S. Hathaway) writes:

>There has been some discussion recently on comp.object about the question
>of what mechanism should be used to bring together two (2) or more objects
>to work with and to affect.  I've suggested that in such cases it's always
>better to have such a "higher authority" than to allocate to an object a
>method which doesn't belong.  To have a mow() method in a lawn object seems
>absurd to me.  Since when does a lawn do anything but grow_crab_grass()?

Mark, you've fallen right into one of the prime conceptual traps of
the object-oriented paradigm: You've swallowed the fallacy that
"object-oriented software models the real world."  Despite the
all-too-frequent hype you might have heard, object-oriented software
does *not* model real-world behavior.  Object-oriented software --
like *any* computer software -- is a formalized model of the behavior
we want to elicit out of a *computer*.  Now, there might be a very
compelling *analogy* between objects-in-the-real-world and
objects-in-the-computer, but it's still nothing more than an
*analogy*.  Every analogy eventually breaks down if you push it too
far.  I would submit that the point where the "real-world" analogy
breaks down is precisely when you start trying to deal with behavior.

Definition: A software object is an encapsulation of a *computer's*
responsibilities *with respect to* some real-world object in its
problem domain.  

A software object encapsulates the computer's responsibilities to know
things (data) and to do things (processing) *pertaining to* some
real-world object.  This knowledge and behavior might bear very little
resemblance to the actual knowledge and behavior that the real-world
object itself might be endowed with.  In general, the purpose of
computer software is *not* to mimic what real-world entities do.  In
fact, the whole point is usually to hold the kind of data and to
perform the kind of processing that real-world entities are *not*
already capable of doing. Otherwise why bother programming?

>The authority which mow()s is not the lawn.  

Of course lawns don't mow themselves -- in the real world.  Of course
there's always some "higher authority" or "agent" actually responsible
for mowing a given lawn -- in the real world.  But if we're talking
about the real world, isn't our lawn-mowing *software* a *part* of
the "real world"?  Isn't the program itself that "higher authority" or
"agent" you're seeking?

Of course, our hypothetical program is probably responsible for mowing
a lot of lawns, and for mowing a lot of different *kinds* of lawns,
and for doing a lot of other things to/for/with/about/upon lawns, and
for doing things to/for/with/about/upon a lot of other things besides
lawns.  That's a lot of different responsibilities -- things are
getting pretty complex.  So it would be beneficial if we could to
encapsulate all those responsibilities in a nice compartmentalized
way.

Let's say we take all the responsibilities that pertain just to one
particular lawn of one particular type, and concentrate those
responsibilities into one cohesive software entity, distinct from
everything else in the system.  For simplicity, we might call this
entity a "lawn" object -- but never in our wildest dreams do we
imagine that it's *really* a lawn.  (Last time I looked inside my
workstation, I didn't see any sod on the motherboard. :-) No, a "lawn"
object is really just a particular chunk of our computing resources
that happens to be devoted to managing a lawn.  The only reason we
don't call it a "lawn manager" or a "lawn controller" is that the role
of "managing" or "controlling" is something you can assume about
*every* software object.  That's what software does: it "manages" or
"controls" or at least "keeps track of" things.  So it would be kind
of redundant to tack on that extra verbiage.  It should just be
understood.

Well ... this assumes that programmers actually *understand* what
programming is all about ...

>Create another object which
>can manipulate the mower and lawn objects.  How about...
>
>  class lawn_mowin_fool is
>    -- states:  poverty, drunk, out of control  :-)
>    proc mow ( lawn is in out yard_of_grass; mower is in lawn_mower ) is
>      ...
>    end mow;
>  end lawn_mowin_fool;
>
>  spirit lawn_mowin_fool is
>    proc mow ( lawn is in out yard_of_grass; mower is in lawn_mower );
>  end lawn_mowin_fool;
>
>  proc lawn_care () is
>    obj lmf is lawn_mowin_fool;
>  begin
>    lmf.mow(MyLawn,SearsSpecial);
>  end lawn_care;
>
>This way you can command lmf to mow MyLawn yard_of_grass with a
>SearsSpecial lawn_mower.
>
>Is that decent or what?
>It beats the heck out of asking a lawn to mow itself!

This is silly.  Does our hypothetical program have any
responsibilities that pertain to some real-world "lawn-mowing fools"?
Are there some real human beings out there that the software is
supposed to give orders to, telling them what lawns to mow with what
lawn mowers?  If so, then I suppose I could understand the need for a
"lawn_mowing_fool" class.  

But if the program itself is supposed to control the lawn mowers
*directly*, then inventing a lawn_mowing_fool class is just an
unnecessary complication.  The computer *itself* is supposed to be the
"lawn-mowing fool".  Or perhaps we've already had experience with a
non-computerized system in which "lawn-mowing fools" -- who sometimes
get "drunk" or "out of control" -- are employed to mow lawns.  Perhaps
we're actually trying to *replace* the "lawn-mowing fools" with
software that can do the job better.  If that's case, then imitating the
behavior of "lawn-mowing fools" in software would be not be "cool" or
"decent" -- it would be totally *foolish*. :-)

The point of this thread was that when you see a C++ member-function
call like:

    theFrontLawn.mowWith(theSearsSpecialMower);

or a Smalltalk method call like:

    theFrontLawn mowWith: theSearsSpecialMower.

you should never feel complled to imagine this as meaning "the front
lawn will mow itself using the Sears Special lawn mower".
Unfortunately, the syntax seems to encourage this kind of
interpretation, and a lot of people even *advocate* this kind of
thinking as being "cool".  However, I (today) believe this is a silly
way of interpreting what object-oriented software does.  Instead, I'd
read this kind of call as meaning "the part of the computer devoted to
the front lawn will mow it (the front lawn) using the Sears Special
lawn mower."  You always have to keep in mind that "theFrontLawn" is
just a chunk of *software* responsible for the front lawn -- and I
think "mowing the lawn" should be an integral part of its
responsibilities, not something off-loaded to another object.

The equivalent call in Ada95 might be something like:

    Lawns.Mow (The_Lawn   => The_Front_Lawn,
               With_Mower => The_Sears_Special_Mower);

(assuming "Lawns" is a package containing a tagged type "Lawn" with a
primitive procedure "Mow"). With this syntax, I'd wager you'd be much
less likely to view "The_Front_Lawn" as somehow "mowing itself".  Yet
this Ada subprogram-call might have exactly the same dynamic-
dispatching semantics as the C++ member function call or the Smalltalk
method invocation above.  That is, "The_Front_Lawn" might be a special
"controlling" parameter, whose run-time type information ("tag" in
Ada95 jargon) would determine which overloaded implementation of "Mow"
to dispatch to.

 >Mark S. Hathaway       <hathawa2@marshall.edu>

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Shameless_Controversial_Marketing_Slogan_For_Favorite_Language =>
      "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>" &
      "Inheritance, hierarchical name-space, generic templates, type-safety, " &
      "readability, C/C++/COBOL/FORTRAN interoperability, numeric precision, " &
      "multi-threading, distributed systems, real-time, safety-critical ...  " &
      "<< A d a 9 5  :  Y o u   n a m e   i t ,  i t ' s   i n   t h e r e >>",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

Re: Subject/Object Confusion Syndrome [was: Ada Objects Help]

[David Weller]

In article <D3MwqH.LDL@swlvx2.msd.ray.com>,
John Volan <jgv@swl.msd.ray.com> wrote:
>dweller@Starbase.NeoSoft.COM (David Weller) writes:
>>Quite right.  Much in the same way that templates in C++ are not
>>explicitly limited to "generic" situations, considering that
>>templates are frequently used to implement bounded arrays in a manner
>>that would make Ada people giggle.
>
>the safety that Ada-like arrays provide.  For instance, are there C++
>compilers out there that can *remove* index-constraint checks when
>they can be proven unnecessary, yet retain them when they are needed?
>
Hmm, this should be crossposted, but I think CodeCenter does.  It's
been a while now.  You see, I've been "C++ Free" since August, 1994
:-)

>On the other hand, are you also implying that Ada95 tagged types are
>in some way inferior as a means of implementing object-oriented
>designs?  If so, what do you mean?
>
Not quite.  What I was saying was that I agreed with Dewar's original
comment -- tagged types do _not_ imply they are limited to
inheritance.  There's some extra goodies you get out of using tagged
types that go past things like inheritance (RTTI, for instance).
What I was _really_ trying to say is that tagged types exhibit the
same philosophical flexibility as templates in C++ (or anything else
you'd like to creatively do a #define on :-)

-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)