Re: Ichibah flames, and flames out over, Ada 9X

Re: Ichibah flames, and flames out over, Ada 9X

[John Goodsen]

>In article <1993Feb25.170827.2178@ennews.eas.asu.edu> 
  stt@spock.camb.inmet.com (Tucker Taft) writes:

>>. . . I hear all this hype about tagged types 
>
>I'm glad to know that at least we are getting some "hype" out
>on Ada 9X.  As any good marketer knows, publicity of any kind is often
>better than no publicity at all. ;-)
>

*often* but not *always*.  In the case of this news thread, the 
"hype" is not helping the perception of Ada 9X in a positive manner...


>> . . . and I see a 
>>few small examples of how they're used with packages/generics/..., 
>>but has anyone implemented a few OO problems with each and compared 
>>them? Semantically, it was easier to add extensiosn to Ada than a 
>>class construct.  But, I think the jury's still out on the "type 
>>extensions 
>> classes" question.  
>
>Actually, there really is not that much difference.  A class-based language 
>happens to have type = module, whereas in package/module-based languages, 
>types are declared inside of modules.
> 

Actually, there's nothing saying that you can't have *MORE* than one
class per module (Ada package) in a class based language.  The class
supports the logical encapsulation of data and operations on that data
(which is the norm in the OO community).  Ada packages would provide
the capability to group related classes and nested classes.

What's the *real* problem with introducing the keyword "class"
instead of "type ... is tagged" ?!?!? 

The tagged type extension doesn't provide the logical encapsulation
mechanism for the associated operations.  So if I *do* add more
than one class (tagged type) to a package, where's the logical
encapsulation of the operations that can be performed on that type?
Leave it up to the programmer to place them in close proximity?
Add more rules to coding guidelines to ensure it?  I'd rather have
the language enforce it...

Is it really that painful to bite the bullet and add the keyword
"class" to the Ada language.  This simple addition to the current
9X approach will provide vendors such as us with a lot more
"perceptual power" to lobby the OO community to seriously look at
using Ada rather than languages such as C++ on their projects.
Once again I'll state it:  

   A *PERCEIVED* feature of an Object Oriented language is that
   it provides a class mechanism with polymorphic behavior.

If Ada 9X comes out without direct support for the concept of class,
then it will have trouble being *PERCEIVED* as a *real* OO language
and you can kiss all those new OO markets bye-bye.

It doesn't matter if I can *achieve* it with tagged types, the simple
fact of the matter is that most people won't dig deep enough into the
concept of tagged types to understand that this is where their
class/inheritance/polymorphism support is embedded.  They will end up
choosing languages like C++ which provide *direct* support for the
class concept.

What do we mean by *direct* support for the class concept?  Simple:

   Add the keyword "CLASS" to the language already !!!

Heck, you've already got the 'CLASS attribute in the language!  Is it
really that much more effort to use "CLASS" instead of 
"TYPE ... IS TAGGED" ???

I'm getting the feeling that the real reason for not adding CLASS to
the language is an extreeeeeeeeeme case of the "Not Invented Here"
syndrome.  In this case the NIH syndrome will hurt the marketing of
Ada as an OO language worse than anything else I can think of
(including the lack of direct support for multiple inheritance, which
is another issue :-)

>If you only declare one type 

   ... [talk about one type per module ]...

>
>But in any case, the debate between Jean Ichbiah and the 
>Ada 9X Mapping/Revision Team (MRT) was not really about 
>"classes" vs. "type extensions," it was whether we 
>should use the keyword "class" in the syntax for type extensions.
>

From reading the above, you can see that my vote is with Mr. Ichbiah...

>The MRT felt that it would simply further confuse the issue by trying
>to cloak our type extensions in the word "class."  
>

"Cloak" ?? Hmmm, so what you're saying is that Ada 9X truly doesn't
have a "class" concept but rather it is a "type extension" ?

>
>So the issue was really about which syntax was most suggestive of the 
>semantics --a kind of issue that unfortunately does not lend itself to 
>objective debate, even though it creates strong feelings on both sides.
>

How about a debate which includes $$ and cents in the marketing
of the language.  Too much technical focus and not enough
market focus on the OO support of Ada 9X will come back to haunt
us ...

>
> . . . People seem to use what they like and OO developers like a
>class construct.  Tagged types are not new and for some reason or
>another were never embraced by the OO community.
>

 ... [ more talk about types inside modules ] ...

>
>Despite the enormous success of C++, there is still a lot of (at least 
>academic) interest in the new OOP languages Modula-3 and Oberon-2, both 
>of which have gone the type-inside-module.  So it may be too early to say that
>"we have a winner."  
>

As the C++ market doubles each year, I don't think there is much
debate who the "winner" will likely be.  C++ has already layed out
most of commercial market battle field for OO languages in the next 10
years.  Wouldn't it be nice to say that "Ada has everything C++ has
*PLUS* tasking, hierarchical libraries, etc..."?  Ada 9X has got to
directly match the class concept of C++ or it will lose too many
potential users to a language which supports it.

When people read an OOD book and it talks about "classes",
"inheritance" and "polymorphism", they will naturally look for these
constructs in a language.  The majority of these people will bypass
Ada 9X when they see that it doesn't have direct support for "classes"
(unless this advice is heeded and the tagged types are changed to
classes :-)


>And for that matter, once you start using one
>of these languages, you will probably discover the type=module vs.
>type-inside-module choice has very little effect on how you design
>and structure your OOP systems.  You will end up creating groups of
>types whether or not the language directly supports the concept of
>"modules."  Similarly, you will often end up having one (primary) type 
>in a module, even if the language allows multiple such types.
>The structure of the problem will probably have more effect on 
>the structure of the program than does the type=module vs. type-inside-module
>decision of the language designer.
>

All the more reason to allow multiple CLASSes in an Ada package?
(which tagged types gives us).  Now all we need to do is make them
look like a class instead of a "tagged type".  Then we've got the best
of both worlds! :-)

Leave Ada types and subtypes as they are in Ada 83.  They serve their
purpose just fine.  Don't confuse them with classes and inheritance.

>> . . .Should be an
>>interesting next few years.
>
>No debate there.
>

It would be even more interesting if Ada 9X became a *real*
commercial competitor of C++ !!!  

  CLASS!  CLASS!  CLASS!

If you don't have class, you won't be considered an OO language!!!
I doubt many reading this c.l.a newsgroup want to hear:

   "Ada's a nice language, but it doesn't have any CLASS!"

:-)



EDITOR'S NOTE: 

  There's more to changing "TYPE ... IS TAGGED" to "CLASS" than
  addressed in this post.  In particular the syntax and semantics of
  encapsulating functions/procedures within a class are left as
  excercise to the MRT. :-) Once again I'll point to Colin Atkinson's
  book on DRAGOON as an excellent example on how to do it...



-- 
John Goodsen
Software Process & Environments
EVB Software Engineering
jgg@evb.com

Re: Ichibah flames, and flames out over, Ada 9X

[David Emery]

In my opinion, the term "class" is too tied up with C++ now.  I'ave
said many times that Ada's greatest strength is that it is *NOT*
C/C++.  Consider the average unwashed programmer who knows (or think
he knows C++).  When he sees the word "class", he will expect C++
class semantics.  If Ada9X does not deliver C++ semantics, then he'll
start screaming that Adas9X "got it wrong."  By not using the
boogie-word "class", we avoid bringing in all of the baggage now
associated with C++ classes.  

On the other hand, people who know multiple OO languages (e.g. Eiffel,
SmallTalk, Modula-3, etc.) will probably jnot be intimidated by the
absence of the "C-word".

We will not convince the died-in-the-wool (pun intended) programmer
who believes C is the greatest thing ever, and C++ is even better (is
this attitude consistent??), taht Adas9X offers a serious alternative.
In many respects, our big hope for Ada9X is for software engineers who
have tried C++ and don't like it, for whatever reason.  

				dave

Re: Ichibah flames, and flames out over, Ada 9X

[Tucker Taft]

In article <1993Mar7.191557.5547@evb.com> jgg@evb.com (John Goodsen) writes:

>>In article <1993Feb25.170827.2178@ennews.eas.asu.edu> 
>  stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>>>. . . I hear all this hype about tagged types 
>>
>>I'm glad to know that at least we are getting some "hype" out
>>on Ada 9X.  As any good marketer knows, publicity of any kind is often
>>better than no publicity at all. ;-)
>>
>
>*often* but not *always*.  In the case of this news thread, the 
>"hype" is not helping the perception of Ada 9X in a positive manner...

Please note the "smiley."

> . . .
>What's the *real* problem with introducing the keyword "class"
>instead of "type ... is tagged" ?!?!? 
>
>The tagged type extension doesn't provide the logical encapsulation
>mechanism for the associated operations.  So if I *do* add more
>than one class (tagged type) to a package, where's the logical
>encapsulation of the operations that can be performed on that type?
>Leave it up to the programmer to place them in close proximity?
>Add more rules to coding guidelines to ensure it?  I'd rather have
>the language enforce it...

I can feel a religious war coming on...

In Ada 83, the package is the encapsulation/information-hiding construct.
Adding a keyword "class" to "type ... is tagged" wouldn't change
that at all, and the keyword substitution was all that Jean Ichbiah 
was proposing.  In fact, he specifically made it 
clear in his proposal that we should *not* change the encapsulation
rules.  After all, his team designed packages in the first place,
with full knowledge of the "class-based" alternatives present
in Simula-67, CLU, etc.

Using classes for encapsulation works great in some circumstances,
but breaks down in others.  If you are familiar with the
way operators work in C++, and the subtleties having to do
with implicit conversions on the "this" parameter versus the
other parameter (the "that" parameter ;-), the appropriate
use of "friends," etc., you begin to see the places where 
class=module approach breaks down.

Consider a typical definition of a "complex" abstract data type in 
Ada 83 (names of operations can be debated in e-mail):

   generic
       type Real is digits <>;
   package Complex_Numbers is
       type Complex is private;
       function "+"(L, R : Complex) return Complex;
       function "*"(L, R : Complex) return Complex;
     . . .
       function Cmplx(Re, Im : Real) return Complex;
       function Re(C : Compex) return Real;
       function Im(C : Compex) return Real;

       type Imaginary is private;
       i : constant Imaginary;   -- This allows "3.5 + 4.0*i" notation
       function "*"(L : Real; R : Imaginary) return Imaginary;
       function "*"(L : Imaginary; R : Real) return Imaginary;
       function "+"(L : Real; R : Imaginary) return Complex;
       function "+"(L : Imaginary; R : Real) return Complex;
     . . .
   private
       type Complex is record
         Re, Im : Real;
       end record;

       type Imaginary is new Real;
   end Complex_Numbers;

How would you write this in a "class-based" language?
At least in C++, operators almost always have to be made "friends"
to work right.  So much for language-enforced encapsulation.  And 
here we have two types, Complex and Imaginary, that are interrelated,
and are naturally defined in a single package.  One would
have to resort to "friends" or perhaps nesting in C++.

The C++ solution might nevertheless be quite elegant, if structured
properly according to reasonable coding guidelines, using the
file=module model where appropriate.  But in this case, we see
that Ada provides better direct encapsulation support than does
a class-based language.

So for some cases, where most operations have only a single
"interesting" parameter, the class-based approach seems more direct.
In other cases (like the above), the package-based approach
seems more direct and supportive of encapsulation.

In any case, Ada 83 clearly chose the package-based approach, and
we are not trying to change that for Ada 9X.  We felt that there
was no need to force Ada programmers to adopt a different way of
doing encapsulation just to get more support for dynamic binding 
and type extension.

We don't see the need to make Ada 9X a "me too" object-oriented
language.  Instead, we want it to combine the best ideas of
Ada 83 and OO languages, into something that advances the state
of the art, not something that trails just behind always trying 
to catch up.  We believe that this approach makes the most sense, 
both technical, and marketing.  Your mileage may of course vary...

> . . .
>John Goodsen
>EVB Software Engineering

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

Re: Ichibah flames, and flames out over, Ada 9X

[Michael Feldman]

In article <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:
>
[ good stuff deleted]

>In any case, Ada 83 clearly chose the package-based approach, and
>we are not trying to change that for Ada 9X.  We felt that there
>was no need to force Ada programmers to adopt a different way of
>doing encapsulation just to get more support for dynamic binding 
>and type extension.
>
>We don't see the need to make Ada 9X a "me too" object-oriented
>language.  Instead, we want it to combine the best ideas of
>Ada 83 and OO languages, into something that advances the state
>of the art, not something that trails just behind always trying 
>to catch up.  We believe that this approach makes the most sense, 
>both technical, and marketing.  Your mileage may of course vary...
>
Hear, hear! It seems the same people who have trashed Ada for being too
stodgy and conservative now want Ada to be merely imitative of the latest
craze. Just because C++ does something in a certain way does NOT make
it the only way, or the only correct way. There is nothing to prevent
Ada from charting its own course. 

Ada's success will be fostered far more by the ready availability of
Ada9X compilers and tools at fair prices, including some free ones so
that we academics can muck around in the source code, than by whether
or not it uses the magic word "class". Instead of constantly kvetching
about classes vs. tagged types, let's get on about the _real_ business.
Freeze the language and get the compilers done.

I meet too many people who describe OOP as follows: "I don't know much
about it, but whatever it is, it's that stuff C++ can do and Ada can't."
It's high time to change this culture of ignorance. It starts in the
schools and works its way outward. The Ada83 "in group" missed this point.
Thank Heaven that the Ada9X "in group" seems (_seems_) to be getting it.
We shall see...

Cheers -

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"The most important thing is to be sincere, 
and once you've learned how to fake that, you've got it made." 
-- old show-business adage
------------------------------------------------------------------------

Re: Ichibah flames, and flames out over, Ada 9X

[Gregory Aharonian]

   With regards to the comments by Tucker and Mike, I think the original
emphasis of the posting is being overlooked.  Like it or not, Ada right now
is in a vicious competition with C++ and Smalltalk, and not doing very well.
Thus it seems to me that some purity will have to be sacrificed with
regards to Ada9X to achieve that level of commercial success necessary for
the DoD to achieve its original goals from Ada83 days.
   Looking at the people involved with Ada9X, there are very few people with
a business stake in the language (DoD types), or a great track record in
promoting Ada in the non-Mandated world (vendor types).  From the outside,
one could make the case that the Ada9X effort is doing its best to improve
the language while maintaining the status quo with regards to a language
that too many in the non-Mandated world can ignorantly, but easily, dismiss.

   I highly doubt that many on the Ada9X effort ever though the following
thought in any of their deliberations:  "If I was spending my own money on
this, what would I want".  From this point of view, the original posting's
call for more features in Ada9X that allows better competition with C++
(and Smalltalk) should be heeded.

Greg Aharonian
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

Re: Ichibah flames, and flames out over, Ada 9X

[Tucker Taft]

In article <SRCTRAN.93Mar8171548@world.std.com> 
  srctran@world.std.com (Gregory Aharonian) writes:

> . . .
>   Looking at the people involved with Ada9X, there are very few people with
>a business stake in the language (DoD types), or a great track record in
>promoting Ada in the non-Mandated world (vendor types).  

This sentence is a bit hard to understand.  But my best guess of what
it means is quite far from the truth.  It seems that you have become
so frustrated with the Ada and DoD worlds that you have stopped talking
to anyone in those worlds.  That's fine, but then you should try to
refrain from generalizing about them.  Rest assured that *many* of the
people involved in Ada 9X have a *huge* stake in the language.  Some
of the best people involved work for small companies that are quite likely
to go belly-up if Ada 9X is a failure.  And those that work for
larger companies have a very large personal stake in the success of Ada 9X,
both economic and career-wise.

> . . . From the outside,
>one could make the case that the Ada9X effort is doing its best to improve
>the language while maintaining the status quo with regards to a language
>that too many in the non-Mandated world can ignorantly, but easily, dismiss.

You could make that case, I suppose, but you would almost 
certainly lose it, since the evidence to support it is incredibly
flimsy; the case on the opposite side is much stronger.

>   I highly doubt that many on the Ada9X effort ever though the following
>thought in any of their deliberations:  "If I was spending my own money on
>this, what would I want".  

You may "highly doubt" it, but I wonder on what basis you formed your opinion.
The truth is, in fact, just the opposite.  This question, at least,
I can answer with some authority ;-).  If we were spending our own money,
we would design Ada 9X the way we did design it.  And in any case,
like many people involved in computer science, spending our own money
is not nearly as painful as spending our own time and energy.
It is our express goal, and always has been, that Ada 9X will be the 
language of choice for systems programmers who have a choice.

> . . .From this point of view, the original posting's
>call for more features in Ada9X that allows better competition with C++
>(and Smalltalk) should be heeded.

There are many ways to skin a cat.  In many cases, imitation is not
the most effective strategy.  Why choose Ada 9X if it makes the same
mistakes that C++ does?  We should learn from the strengths and
weaknesses of other languages, and advance the state of the art, 
not solidify it around a 1985-vintage design.

Like others, I welcome your efforts to "wake up" the Ada community.
But you only serve to dilute your message by making unnecessary
generalizations based on lack of direct knowledge.  If you really
care, why not try to meet a few of the people involved with the Ada 9X
project?  If you don't, then don't dilute your message by making
unwarranted claims about us.

>Greg Aharonian

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

Re: Ichibah flames, and flames out over, Ada 9X

[C. Michael Holloway]

>>>>> On 9 Mar 93 14:20:13 GMT, stt@spock.camb.inmet.com (Tucker Taft) said:

tt> ...  If we were spending our own money, we would design Ada 9X the way we
tt> did design it.  And in any case, like many people involved in computer
tt> science, spending our own money is not nearly as painful as spending our
tt> own time and energy.  It is our express goal, and always has been, that
tt> Ada 9X will be the language of choice for systems programmers who have a
tt> choice.  ...  There are many ways to skin a cat.  In many cases,
tt> imitation is not the most effective strategy.  Why choose Ada 9X if it
tt> makes the same mistakes that C++ does?  We should learn from the
tt> strengths and weaknesses of other languages, and advance the state of the
tt> art, not solidify it around a 1985-vintage design.

From a purely technical point of view, I agree with this completely. 
Mr. Taft and the mapping/revision team have designed an excellent language --
one that I would choose for systems programming, were I to do such
programming and to have such a choice. 

Were technical factors the only factors that mattered, then Ada 9X would be a
resounding success; unfortunately, technical factors are rarely even the most
important ones.  We can all think of numerous examples of technically
inferior products that have become successes (to avoid offending someone,
I'll refrain from listing a few examples that come to my mind).

This is especially true in programming languages, because in many companies,
agencies, projects, etc, technically knowledgeable people are not the ones who
make the decisions as to what programming language will be used.  That's not
the way that things ought to be, but it is the way that things are in many
places. 

Personally, I am fully persuaded by Mr. Taft's arguments for the current
syntax and semantics of the object-oriented aspects of Ada 9X.  But that
syntax may well prevent the language from being used in many places; enough
places, I am afraid, to doom it to commercial failure.  In fact, if Mr. Taft
were to make these arguments to high level managers, the end of the
discussion might well resemble Paul's discussion with Festus in Acts 26 (to
paraphrase):

  Now as Mr. Taft thus made his defense, Mr. Manager said with a loud voice,
  "Tucker, you are beside yourself!  Much learning is driving you mad!"

  But he said, "I am not mad, most noble manager, but speak the words of
  truth and reason."

Now, Paul was discussing eternal truth and could not compromise his message,
but since Ada 9X is a little more temporal, some compromise ought to be
possible.

=================================================================
C. Michael Holloway             Email: c.m.holloway@LaRC.NASA.GOV
NASA Langley Research Center    Fax:   1 804 864 4234
Mail Stop 130                   Voice: 1 804 864 1701
Hampton VA 23681-0001 
--
=================================================================
C. Michael Holloway             Email: c.m.holloway@LaRC.NASA.GOV
NASA Langley Research Center    Fax:   1 804 864 4234
Mail Stop 130                   Voice: 1 804 864 1701
Hampton VA 23681-0001           Verse: Psalm 97:1

Re: Ichibah flames, and flames out over, Ada 9X

[Gregory Aharonian]

>This sentence is a bit hard to understand.  But my best guess of what
>it means is quite far from the truth.  It seems that you have become
>so frustrated with the Ada and DoD worlds that you have stopped talking
>to anyone in those worlds.  That's fine, but then you should try to
>refrain from generalizing about them.  Rest assured that *many* of the
>people involved in Ada 9X have a *huge* stake in the language.  Some
>of the best people involved work for small companies that are quite likely
>to go belly-up if Ada 9X is a failure.  And those that work for
>larger companies have a very large personal stake in the success of Ada 9X,
>both economic and career-wise.

Tucker,
	Let me make it easier to understand.  Consider the general trade
press in computing, with such publications as Computerworld, Software,
Datamation, Mid-Range Systems, Computer Language, Infoworld, Open Systems
Today, Computer Design, the IEEE and ACM general publications, Data
Management Review, and others.	I rarely, if ever, see any ads for Ada
compilers from most of the companies reflected in the Ada9X effort.  Nothing.
  	Consider the general (by general, I mean non-Mandated) trade shows.
Object World, CASE World, Software Engineering XX, etc.  Rarely, if ever,
do I see much of an Ada presence by most of the companies reflected in the
Ada9X effort.
	Sure, I believe that you guys have a "huge" stake in the Ada9X
effort, but based on this behavior analysis, it seems that the stake you
are striving for is the nice cozy Mandated world.  I do not see much
evidence that you guys are taking the evangelizing of Ada seriously,
outside the Mandated world.  I rarely if ever see ads for Ada, trade
show booths for Ada, bingo cards in card decks for Ada, direct mail
pieces for Ada, anything for Ada.
 	I just don't see anything being done to better promote Ada.
Nothing from the DoD, nothing from DoD contractors, and especially nothing
from Ada compiler vendors.  You tell me where are the continually running
ads for Intermetrics, Alsys, Meridian, Verdix, Aetech, etc.  Scattershot
is what I see at best, especially compared to the advertising square inch
space for other languages.

	Thus Tucker, my original concern still holds.  I barely see any
presence of many of the Ada9X people in the non-Mandated world, and am
afraid that what will come out of the Ada9X effort will be a great
language that will be even less accepted in the non-Mandated world than
Ada83.

	Prove me wrong that there you guys have a much bigger presence
in the non-Mandated world. If nothing else, explain to me why Intermetrics
(at least in Cambridge) seems to keep on losing its best programmers
(many of whom are my friends) to numerous C/C++ efforts in the Boston area.

	If nothing else, how about a round of golf at Fresh Pond to
settle this one way or the other.  If you win, I'll admit that Ada has
behind it the best marketing campaign in advertising history, and if I
win, you'll admit that you are all a bunch of parasites (in the strictly
biological analogy meaning).

Greg Aharonian
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

Re: Ichibah flames, and flames out over, Ada 9X

[Harry Koehnemann]

In article <SRCTRAN.93Mar8171548@world.std.com> srctran@world.std.com (Gregory Aharonian) writes:
>From this point of view, the original posting's
>call for more features in Ada9X that allows better competition with C++
>(and Smalltalk) should be heeded.

All I wanted to know was why type extensions were chosen over the
class construct (which I think Mr. Taft addressed).  I've always had
the question - Do classes or type extensions map better to typical OO
problems?  I've never seen any studys that compared the two.  I figured
that, since the OO additions were perhaps that largest change in a
rather costly revision process, someone might have looked into why
classes were so popular - maybe even done that study I've been looking
for.

Another point is that neither construct is new (despite what I hear on
c.l.a) and classes seem to have "won" in the OO world.  If Ada wants to
play ball in that community, I feel it's got a pretty big sell ahead of
itself - which could probably start with that study comparing classes
and type extensions for some model OO problems.  (kindof like doing the
feasibility study after the products built)

People seem to enjoy finding flaws in Ada.  Will type extensions be
another one of those problem areas people love to point at when talking
about Ada?  ("Type extensions!  We saw type extensions way back in...")
Either way, I think it's a big area of risk for 9X.
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

Re: Ichibah flames, and flames out over, Ada 9X

[Michael Feldman]

In article <1993Mar9.171230.28664@ennews.eas.asu.edu> koehnema@enuxhb.eas.asu.edu (Harry Koehnemann) writes:
>
>All I wanted to know was why type extensions were chosen over the
>class construct (which I think Mr. Taft addressed).  I've always had
>the question - Do classes or type extensions map better to typical OO
>problems?  I've never seen any studys that compared the two.  I figured

Ummm - you might start with Rosen's article in Nov. 92 Comm. ACM.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"The most important thing is to be sincere, 
and once you've learned how to fake that, you've got it made." 
-- old show-business adage
------------------------------------------------------------------------

Re: Ichibah flames, and flames out over, Ada 9X

[Larry M. Jordan]

In article <SRCTRAN.93Mar8171548@world.std.com> srctran@world.std.com (Gregory Aharonian) writes:
>   With regards to the comments by Tucker and Mike, I think the original
>emphasis of the posting is being overlooked.  Like it or not, Ada right now
>is in a vicious competition with C++ and Smalltalk, and not doing very well.

[lots of excellent stuff deleted]

>
>this, what would I want".  From this point of view, the original posting's
>call for more features in Ada9X that allows better competition with C++
>(and Smalltalk) should be heeded.
>

Let me register my agreement with Greg.  I'd sure like to know how
many others feel this way. 

--Larry

Re: Ichibah flames, and flames out over, Ada 9X

[Harry Koehnemann]

In article <1993Mar8.162831.8767@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>I meet too many people who describe OOP as follows: "I don't know much
>about it, but whatever it is, it's that stuff C++ can do and Ada can't."

Hmmm.  Most the OO people I know talk about OO as "objects, classes,
and inheritance" and discuss objects as active entities (rather than
passive as they are with tagged types).  I don't mean to downplay the
work done on 9X and I personally haven't resolved the "Classes vs. Type
Extensions" question yet, but these are likely arguments you're going to
get from the OO community.

Every OO text I know of defines an OO language as Objects, Classes, and
Inheritance.  Granted type extensions yield a form of classification,
but it is not as evident as it is in a language with a construct called
"class".  And, we have yet to determined whether that form of
classification is as useful as a class.

Second, OO principles are very big on objects being active.  I write
Obj.Operation rather than Operation(Obj).  In fact, people have
hinted at Ada83 being OO because of the tasking mechanism, simply
because it uses hte proper notation (and that tasks have an internal
thread of control).  How does my OO design translate into a language
where objects aren't active?

>It's high time to change this culture of ignorance. It starts in the
>schools and works its way outward. The Ada83 "in group" missed this point.
>Thank Heaven that the Ada9X "in group" seems (_seems_) to be getting it.
>We shall see...

I agree completely.  If you're going to sell Ada as object-oriented,
you'd better be prepared to defend that statment.  I disagree with
your assessment of the OO community.  Most of them really know their
shit when it comes to OOness and we sure as hell don't want to loose
arguments because we are ignorant of the facts.  I'm just getting
prepared for what's likely ahead.

Adios.
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

Re: Ichibah flames, and flames out over, Ada 9X

[Michael Feldman]

In article <1993Mar9.174925.29392@ennews.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) writes:
>In article <1993Mar8.162831.8767@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>>I meet too many people who describe OOP as follows: "I don't know much
>>about it, but whatever it is, it's that stuff C++ can do and Ada can't."
>
>Hmmm.  Most the OO people I know talk about OO as "objects, classes,
>and inheritance" and discuss objects as active entities (rather than
>passive as they are with tagged types).  I don't mean to downplay the
>work done on 9X and I personally haven't resolved the "Classes vs. Type
>Extensions" question yet, but these are likely arguments you're going to
>get from the OO community.

Oh, you and I are tekkies. I mean the project managers, the ones who get
to make the decisions. Some of them even have gold braid on their starched
shirts.
>
>Every OO text I know of defines an OO language as Objects, Classes, and
>Inheritance.  Granted type extensions yield a form of classification,
>but it is not as evident as it is in a language with a construct called
>"class".  And, we have yet to determined whether that form of
>classification is as useful as a class.

Correct. 'Course the OO texts have picked up on a recent bit of jargon.
They may not have a monopoly on truth; they've just co-opted the buzzwords.
>
>Second, OO principles are very big on objects being active.  I write
>Obj.Operation rather than Operation(Obj).  In fact, people have
>hinted at Ada83 being OO because of the tasking mechanism, simply
>because it uses hte proper notation (and that tasks have an internal
>thread of control).  How does my OO design translate into a language
>where objects aren't active?

You are obviously not in the category of folks I was referring to.
>
>>It's high time to change this culture of ignorance. It starts in the
>>schools and works its way outward. The Ada83 "in group" missed this point.
>>Thank Heaven that the Ada9X "in group" seems (_seems_) to be getting it.
>>We shall see...
>
>I agree completely.  If you're going to sell Ada as object-oriented,
>you'd better be prepared to defend that statment.  I disagree with
>your assessment of the OO community.  Most of them really know their
>shit when it comes to OOness and we sure as hell don't want to loose
>arguments because we are ignorant of the facts.  I'm just getting
>prepared for what's likely ahead.
>
The folks I mean are not in "the OO community." I meant what I said QUITE
LITERALLY: they know little about OO but somebody, somewhere, told them
that C++ could do it and Ada couldn't. They haven't got the foggiest idea
whether Objects, Classes, Inheritance, etc., would make a damn bit of 
difference in the cost-effectveness of their project. But somebody told
'em that OO was the greatest thing since sliced bread, reason enough
to fight the Ada Mandate. Arrant nonsense. But it's out there. It's
enough to make your hair stand on end. And it's your tax money and mine.

Mike

Re: Ichibah flames, and flames out over, Ada 9X

[Tom Wicklund]

In <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:

>I can feel a religious war coming on...

I don't want to start a religious war, but I think Mr. Taft's
experience with C++ is too limited.  On the other hand, I've never
done any real Ada programming so I apologize in advance for any errors
in my knowledge of Ada.

Both C++ and Ada have their strengths and weaknesses, I'm not fond of
either as a "favorite" langauge though I have some preference for C++
due primarily to better familiarity.

>Using classes for encapsulation works great in some circumstances,
>but breaks down in others.  If you are familiar with the
>way operators work in C++, and the subtleties having to do
>with implicit conversions on the "this" parameter versus the
>other parameter (the "that" parameter ;-), the appropriate
>use of "friends," etc., you begin to see the places where 
>class=module approach breaks down.

However, C++ doesn't use a class=module approach.  You're comment
applies more to a language like Eiffel.  C++ uses the class to control
information hiding, similar to (one function of) Ada's package.

>Consider a typical definition of a "complex" abstract data type in 
>Ada 83 (names of operations can be debated in e-mail):

>   generic
>       type Real is digits <>;
>   package Complex_Numbers is
>       type Complex is private;
>       function "+"(L, R : Complex) return Complex;
>       function "*"(L, R : Complex) return Complex;
>     . . .
>       function Cmplx(Re, Im : Real) return Complex;
>       function Re(C : Compex) return Real;
>       function Im(C : Compex) return Real;

>       type Imaginary is private;
>       i : constant Imaginary;   -- This allows "3.5 + 4.0*i" notation
>       function "*"(L : Real; R : Imaginary) return Imaginary;
>       function "*"(L : Imaginary; R : Real) return Imaginary;
>       function "+"(L : Real; R : Imaginary) return Complex;
>       function "+"(L : Imaginary; R : Real) return Complex;
>     . . .
>   private
>       type Complex is record
>         Re, Im : Real;
>       end record;

>       type Imaginary is new Real;
>   end Complex_Numbers;

>How would you write this in a "class-based" language?
>At least in C++, operators almost always have to be made "friends"
>to work right.

No they don't.  I suggest you look at the GNU g++ library
implementation of complex, which I summarize below.  Note that there
are NO friend functions.  There are differences, reflecting the
differences between Ada's and C++'s approaches to types and
differences in the approach to the implementation.

On the other hand, Ada packages are analagous to providing a "friend"
declaration between all types declared in the package.  If "friends
are so bad, then Complex and Imaginary should be in different packages
so they can't get at each other's internals (which is basically what a
C++ friend declaration does).

NOTE:  I've edited the following somewhat to remove inline function
implementations and several of the operations.

/* 
Copyright (C) 1988 Free Software Foundation
    written by Doug Lea (dl@rocky.oswego.edu)

This file is part of GNU CC.
*/

class Complex
{
protected:			// analagous to Ada's private part
  double           re;
  double           im;

public:
  inline double real() const;	// get real part of number
  inline double imag() const;	// get imaginary part of number

  // Create a complex number
  inline           Complex();
  inline           Complex(const Complex& y);
  inline           Complex(double r, double i=0);

  // assignment
  inline Complex&  operator =  (const Complex& y);

  // Basic operations (add to number, subtract from number, etc).
  inline Complex&  operator += (const Complex& y);
  inline Complex&  operator += (double y);
  inline Complex&  operator -= (const Complex& y);
  inline Complex&  operator -= (double y);
  inline Complex&  operator *= (const Complex& y);
  inline Complex&  operator *= (double y);

  Complex&         operator /= (const Complex& y); 
  Complex&         operator /= (double y); 
};

// Other operations on Complex.  No friend functions needed.

// Comparison operations.
int operator == (const Complex& x, const Complex& y);
int operator == (const Complex& x, double y);

int operator != (const Complex& x, const Complex& y);
int operator != (const Complex& x, double y);

Complex operator - (const Complex& x);	  // negation
Complex conj(const Complex& x);		  // conjugate

// Arithmetic:
Complex operator + (const Complex& x, const Complex& y);
Complex operator + (const Complex& x, double y);
Complex operator + (double x, const Complex& y);

Complex operator - (const Complex& x, const Complex& y);
Complex operator - (const Complex& x, double y);
Complex operator - (double x, const Complex& y);

// Similarly for *, /.

// More complicated operations:

Complex polar(double r, double t = 0.0);
Complex cos(const Complex& x);
Complex sin(const Complex& x);

// (removed abs, norm, arg, sinh, cosh, exp, log, pow (power), sqrt).


>  So much for language-enforced encapsulation.  And 
>here we have two types, Complex and Imaginary, that are interrelated,
>and are naturally defined in a single package.  One would
>have to resort to "friends" or perhaps nesting in C++.

I'm sure a C++ example could be created with classes Real, Imaginary,
and Complex.

There are also things which a C++ version could do and Ada can't.  For
instance, I don't think your Ada version as specified above allows
assignment between types, in particular, how do I assign an imaginary
value to a complex?

Complex := Imaginary;		   -- type violation.
Complex := Cmplx(Real, Imaginary); -- defined as Cmplx(Real, Real)
Complex := (0, Imaginary);	   -- private type.

I assume I have to get the package implementor to write a new function:

function Cmplx(re: Real; Im: Imaginary) return Complex;

Or alternately something like:

Complex := Cmplx(Re, Real(Im));	   -- use explicit conversion.
	   `			   -- can I do this to generics?

>The C++ solution might nevertheless be quite elegant, if structured
>properly according to reasonable coding guidelines, using the
>file=module model where appropriate.  But in this case, we see
>that Ada provides better direct encapsulation support than does
>a class-based language.

And one could write a very poorly structured Ada implementation which
violates package structures.  You may have some protection above
because the package is generic, I'm not familiar enough with Ada
generics.

I do agree that it's easier to create poorly packaged code in C++ than
in Ada.  From that standpoint Ada provides better encapsulation, but
it's by no means ideal.

There is also a problem discussed extensively in the Ada 9X materials
about how to handle mixing operations of types Matrix and Vector, so
Ada's encapsulation has it's problems also (this particular problem
isn't easy in either class based languages like Eiffel or in C++
either, though solutions can be done in any of these langauges).

>In any case, Ada 83 clearly chose the package-based approach, and
>we are not trying to change that for Ada 9X.  We felt that there
>was no need to force Ada programmers to adopt a different way of
>doing encapsulation just to get more support for dynamic binding 
>and type extension.

Regardless of the above, you're right to maintain Ada's encapsulation
philosophy.  I don't like Ada's approach as much as some others, but
there's nothing inherently wrong with it.

>We don't see the need to make Ada 9X a "me too" object-oriented
>language.  Instead, we want it to combine the best ideas of
>Ada 83 and OO languages, into something that advances the state
>of the art, not something that trails just behind always trying 
>to catch up.  We believe that this approach makes the most sense, 
>both technical, and marketing.  Your mileage may of course vary...

True, though I'm not sure Ada 9X is advancing the state of the art
past other languages (personal opinion).

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

Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

[Magnus Kempe]

Taft showed how a package allows one to encapsulate _several_ types
and their operations, providing such natural and efficient notations
as "A := 2 + 3 * i;" ("A" is of type Complex and "i" is of type
Imaginary; "+" and "*" are the operations).

The crux of Taft's example is that Ada allows one to declare
_several_ types _together_ and thus be able to easily provide
an efficient subprogram operating on _several_ objects of
_different_ types.  All this can be achieved within a package
with the safety provided by private types (since no one else is
allowed to proclaim itself so "friendly" as to see the private
parts of your package...).

To achieve this, operators would have to be "friends" in C++,
because of its equation "module = class"; however, the problem
with such an approach is that _anyone_ can then claim to be a
"friend", and therefore _anyone_ can break the abstraction of
the class.

C++ "friends" break the encapsulation and its equation becomes
an approximation: "a class with friends is almost a module".


wicklund@intellistor.com (Tom Wicklund) answered Taft with
an irrelevant example:
: 
: I suggest you look at the GNU g++ library implementation of complex,
: which I summarize below.  Note that there are NO friend functions.

Of course, there are no friends in your C++ code (not repeated here),
since the C++ class you included does _not_ propose _two_ types
and operations working on objects of both types.  (BTW, I'd rather
see a discussion of principles with approriate examples; pouring
hundreds of lines of C++ code in comp.lang.ada is uninteresting.
Thank you.)


To summarize, the crucial concepts involved are the following: we want
a natural notation to declare several types and associated, efficient
subprograms operating on several parameters of different types, and we
want all this while preserving the abstraction in its encapsulation and
type safety.  Ada satisfies such software engineering requirements, and
Ada 9X will soon provide still more programming power to satisfy still
more software engineering requirements.  (How great!)

-- 
Magnus Kempe                "No nation was ever drunk when wine was cheap."
magnus@lglsun.epfl.ch                                   -- Thomas Jefferson

Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

[Dag Bruck]

In <comp.lang.ada> magnus@lglsun.epfl.ch (Magnus Kempe) writes:
>
>To achieve this, operators would have to be "friends" in C++,
>because of its equation "module = class"; however, the problem
>with such an approach is that _anyone_ can then claim to be a
>"friend", and therefore _anyone_ can break the abstraction of
>the class.

This is incorrect.

A class grants friendship to other functions or classes, which means
that the author of a class controls who gets access to the private
members of the class.  You cannot grant yourself access to any random
class.

			-- Dag Bruck

Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

[Magnus Kempe]

dag@control.lth.se (Dag Bruck) writes:
: A [C++] class grants friendship to other functions or classes, which means
: that the author of a class controls who gets access to the private
: members of the class.  You cannot grant yourself access to any random
: class.

If your class Foo grants "friendship" to a function/class Bar, _anyone_
can write such a function/class and, having granted itself "friendliness",
will have access to the internals of Foo.

To repeat: contrary to Ada, C++ does not provide a safe means to create
subprograms acting on parameters of two or more types (classes).  In
C++, either you write an unsafe class because the language lacks the
concept of a module, or you twist around with .h files and say good-bye
to limited, separate recompilations.

-- 
Magnus Kempe                "No nation was ever drunk when wine was cheap."
magnus@lglsun.epfl.ch                                   -- Thomas Jefferson

Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

[Dag Bruck]

In <comp.lang.ada> magnus@lglsun.epfl.ch (Magnus Kempe) writes:
>dag@control.lth.se (Dag Bruck) writes:
>: A [C++] class grants friendship to other functions or classes, which means
>: that the author of a class controls who gets access to the private
>: members of the class.  You cannot grant yourself access to any random
>: class.
>
>If your class Foo grants "friendship" to a function/class Bar, _anyone_
>can write such a function/class and, having granted itself "friendliness",
>will have access to the internals of Foo.

If we assume that the author of a class also writes the
classes/functions he/she grants friendship, the "one definition rule"
prohibits you from writing a second function or class with the same
name.

The alternative, that the author grants friendship without actually
writing the friend classes/functions, seems highly unlikely.

If you manipulate library files, for example, replace standard
functions with functions you have written yourself, then you can of
course get access to anything.  You may also patch the symboltable or
the objectcode itself.  However, I doubt that Ada is safer in this
respect.

There is a much simpler way to break encapsulation (and I'm sure
Magnus Kempe wants to hear it): write a your own class with the same
contents and copy the bits from the protected object to a look-alike
object with standard C function "memcpy".

I doubt that "unsafe" features of this nature is of any real interest.
Can anyone give a plausible example?


			-- Dag

Re: Ichibah flames, and flames out over, Ada 9X

[Larry M. Jordan]

I must agree with the recent posts that express concern over
Ada 9X's OOP features not be recognized as such.  I'm not an 
'average' programmer (I know Ada, C++, Turbo Pascal, a number 
of Modula-2s with OOP, Oberon-2).  Yet, I had no little difficulty 
reading the Ada 9X rationale and understanding just how 9X will 
support OOP.

I think introducing the keyword 'tagged' is a mistake.  It sure
didn't facilitate my understanding.  It wasn't until I read
the paper by Dismukes and Rome that I realized, 'Oh, this
isn't so different after all.'  My impression (and it may be only
mine) is that 'tagged' is an implementation detail that has
somehow leaked out.  What an ugly word it is (and how many times 
will it be misspelled!--one 'g' or two?).  Ichbiah's suggestion
seems preferable.

There will probably be better sources for learning Ada 9X OOP
features (there probably are now).  But at the time, the rationale was
all I had.  Maybe a book/monograph needs to be written that's palatable
to the pop programming culture, speaking to them at their level, an
'Ada 9X Primer'?!  Until there is, I'm afraid that Ada 9X OOP
will be preceived as something 'unfamiliar'.

--Larry

Re: Ichibah flames, and flames out over, Ada 9X

[David Weller]

In article <1nip3kINNb2c@news.aero.org> jordan@aero.org (Larry M. Jordan) writes:
>I must agree with the recent posts that express concern over
>Ada 9X's OOP features not be recognized as such.  I'm not an 
>'average' programmer (I know Ada, C++, Turbo Pascal, a number 
>of Modula-2s with OOP, Oberon-2).  Yet, I had no little difficulty 
>reading the Ada 9X rationale and understanding just how 9X will 
>support OOP.
>

Indeed, it IS a nontrivial document aimed at the Ada fluent (and
C++/CLOS/Smalltalk fluent, to a degree).  I'm not so sure this 
makes it a Bad Thing.  There has been considerable discussion
about simplifying the Rationale (right, Tuck?).

>I think introducing the keyword 'tagged' is a mistake.  It sure
>didn't facilitate my understanding.  It wasn't until I read
>the paper by Dismukes and Rome that I realized, 'Oh, this
>isn't so different after all.'  My impression (and it may be only
>mine) is that 'tagged' is an implementation detail that has
>somehow leaked out.  What an ugly word it is (and how many times 
>will it be misspelled!--one 'g' or two?).  Ichbiah's suggestion
>seems preferable.
>

Yeah, and I've lost count of how many Ada programmers I've taught
that can't spell seperate(sic) :-)

Tucker would be quick to point out that the word "record" is also
an implementation detail, but that it's become generally accepted
in the programming domain.  Frankly, I don't care for the word
"tagged" either, but "class" doesn't fit in its place.  Do you 
have an alternate suggestion?

One other thing that's bothered me -- why are we raising such a fuss
about the word "tagged" to mean "this record may have it's state
description extended"?  Perhaps we're being pedantic?  Where were 
such arguments when the "C" language reference said "*" means
"pointer"?  :-)   (Smiley for the humor impaired)

>There will probably be better sources for learning Ada 9X OOP
>features (there probably are now).  But at the time, the rationale was
>all I had.  Maybe a book/monograph needs to be written that's palatable
>to the pop programming culture, speaking to them at their level, an
>'Ada 9X Primer'?!  Until there is, I'm afraid that Ada 9X OOP
>will be preceived as something 'unfamiliar'.
>

If you'll look in the Ada 9X Project Plan (whatever), you'll
see there's TWO 9X primers: one for the Ada literate and one for
the "Real Language" impaired :-)  I believe there's also a
plan for video tapes (hopefully it will be a little more lively
than the ones Alsys sold back in the mid 80's).  I'm not sure
of the release dates for the primers, but I'm sure it won't be before
the ANSI acceptance of 9X.

>--Larry
>

dgw

Re: Ichibah flames, and flames out over, Ada 9X

[Michael Feldman]

In article <1993Mar9.152454.739@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (David Weller) writes:
>
>If you'll look in the Ada 9X Project Plan (whatever), you'll
>see there's TWO 9X primers: one for the Ada literate and one for
>the "Real Language" impaired :-)  I believe there's also a
>plan for video tapes (hopefully it will be a little more lively
>than the ones Alsys sold back in the mid 80's).  I'm not sure
>of the release dates for the primers, but I'm sure it won't be before
>the ANSI acceptance of 9X.
>
Ummm - anyone know who's writing it?

Mike

Re: Ichibah flames, and flames out over, Ada 9X

[Tucker Taft]

In article <1993Mar9.210350.14567@seas.gwu.edu> 
  mfeldman@seas.gwu.edu (Michael Feldman) writes:

>In article <1993Mar9.152454.739@sei.cmu.edu> 
>  wellerd@ajpo.sei.cmu.edu (David Weller) writes:
>>
>>If you'll look in the Ada 9X Project Plan (whatever), you'll
>>see there's TWO 9X primers: one for the Ada literate and one for
>>the "Real Language" impaired :-)  I believe there's also a
>>plan for video tapes (hopefully it will be a little more lively
>>than the ones Alsys sold back in the mid 80's).  I'm not sure
>>of the release dates for the primers, but I'm sure it won't be before
>>the ANSI acceptance of 9X.
>>
>Ummm - anyone know who's writing it?

John Barnes is working on the 9X Rationale these days,
with help from other members of the Mapping/Revision Team.  
Some version of the rationale will accompany the documents
circulated for ANSI Canvass/ISO balloting.

Several video tapes will be produced, some (short) "glossy" ones
for CEOs, CIOs, chief technical officers, etc., and some (longer) 
"pragmatic" ones for programmers, both Ada 83 and C/C++ types.
These will probably not be ready until after the balloting
process is nearly complete.

>Mike

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

Re: Ichibah flames, and flames out over, Ada 9X

[Michael Feldman]

In article <1993Mar12.144940.18386@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:

[stuff deleted]
>
>John Barnes is working on the 9X Rationale these days,
>with help from other members of the Mapping/Revision Team.  
>Some version of the rationale will accompany the documents
>circulated for ANSI Canvass/ISO balloting.
>
A Rationale is fine, but the original question asked about the promise
of _primers_ written to _teach_ 9X. This has been promised in the last few
versions of the transition plan. Is this happening? (I can tell you for sure
that nobody has asked _me_ to write it :-))

Mike Feldman

Re: Ichibah flames, and flames out over, Ada 9X

[Robert Firth]

In article <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:

>So for some cases, where most operations have only a single
>"interesting" parameter, the class-based approach seems more direct.
>In other cases (like the above), the package-based approach
>seems more direct and supportive of encapsulation.

Thanks, Tucker, and I agree.  Those enamoured of formality might like
to revisit Part I and the first half of Part II of Russell and
Whitehead's 'Principia Mathematica'.  They discuss at great length
the same issue in formal logic: whether relations between two different
classes can be represented adequately in terms of attributes of one
class or the other.  The answer, not surprisingly, is yes, for special
cases, but no, for the general case.  In these terms, the class/attribute
model represents a reversion to the Aristotelian approach, where the
only relations are predication and inclusion.

Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

[John Goodsen]

magnus@lglsun.epfl.ch (Magnus Kempe) writes:
>
>If your class Foo grants "friendship" to a function/class Bar, _anyone_
>can write such a function/class and, having granted itself "friendliness",
>will have access to the internals of Foo.
>
Oh my!  And shame, shame, shame on you for even thinking imitating
my "BAR".  This argument is remeniscent of the facist arguments which
have the common theme of "you might use it wrong, therefore I want
to keep you from using it at all".  BTW, you won't get too far in
the link stage with both "BAR"s in the system (multiply defined identifiers
and such..)

>
>To repeat: contrary to Ada, C++ does not provide a safe means to create
>subprograms acting on parameters of two or more types (classes).  In
>C++, either you write an unsafe class because the language lacks the
>concept of a module, or you twist around with .h files and say good-bye
>to limited, separate recompilations.
>

"UNSAFE CLASS" ???
Huh?  Come now!  "friendship" is not necessarily unsafe.  Only if you use
it wrong.  True, Ada packaging and "classtypes" (I refuse to use
tagged type syntax anymore ;-) overcome this *perceived* defect
in C++, but to *twist* the truth in suggesting that you lose separate
recompilations is not responsible.  In fact to the contrary, the *friend*
concept allows for separate recompilation of these related classes
and functions.  Ada packages *REQUIRE* recompilation of all related 
"classtypes" (there it is again, isn't it a pretty syntax ;-), since they're
in the same package.  


-- 
John Goodsen
Software Process & Environments
EVB Software Engineering
jgg@evb.com