HDTenEightyP/NetNews huggingface dataset:
From: rmartin@stripe.Rational.COM (Bob Martin)
Subject: Re: Non-Compatible Type Inheritance in Booch's Method?
Organization: Rational
Date: Tue, 26 Jan 1993 23:38:34 GMT

880445p@dragon.acadiau.ca (Ravi Palepu) writes:

|rmartin@thor.Rational.COM (Bob Martin) writes:

|>protected forms.

|>		-----------> public inheritance

|>		--|--------> protected inheritance

|>		--||-------> private inheritance

|>The old, "inherits (new type) relationship is now a private
|>inheritance relationship.  It indicates that the inheriting class does
|>not conform to the ISA relationship.  The public interface of the
|>base class is not visible to clients of the subclass.  Thus, the
|>subclass is a new type, rather than a type which is compatible with
|>the base class....

|Is the 'new' notation becoming less general and more focused on C++?
|Possibly, other types of inheritance can be mapped onto the three
|described above. Smalltalk class inheritance can be mapped onto
|protected inheritance (although it offers a lesser degree of encapsulation).

Although some C++isms have been added to the notation, it is still
very general and applicable to most OO languages.

The inheritance used in Smalltalk is "public", i.e. the interface of
the derived class is a superset of the interface of the base class.
In private inheritance the interface of the derived class is unrelated
to the interface of the base class.  Thus it represents a new type,
incompatible with the base.  Moreover, object of the derived class
cannot be directly converted into objects of the private base class...

--
Robert Martin       | Design Consulting    | Training courses offered:
R. C. M. Consulting | rmartin@rational.com |  Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004  |  Object Oriented Design
Green Oaks, Il 60048| Fax: (708) 918-1023  |  C++
Newsgroups: comp.object,comp.software-eng
From: khalsa@SanDiego.NCR.com (G.K. Khalsa)
Subject: Re: How About Using Bootch for Analysis?
Reply-To: g.k.khalsa@SanDiego.NCR.com (G.K. Khalsa)
Organization: NCR Engineering and Manufacturing, San Diego, CA
Date: Wed, 27 Jan 1993 01:49:37 GMT

In article <mmaccorm.68@fox.nstn.ns.ca> mmaccorm@fox.nstn.ns.ca
(Mike Mac Cormack) writes:

>My company is currently trying to decide which object oriented methodology 
>to use for our next project (approx. about 10,000 lines of code) and we had 
>the following questions:
>
>1) Can you use Bootch for both analysis and design?  The first 3 steps of 
>his method are almost identical to Coad/Yourdon's OOA.

Booch has a rich set of modeling concepts and a notation to support them.
My personal opinion is that the handling of aggregation (Coad/Yourdon's
whole-part) is the weakest part.  But the real issue is _what_ you are
modeling. This distinction divides analysis from design.  Although there
is an inevitable intertwining of specification and implementation, we
must do our best to model the 'what' in analysis and add the 'how' in
design.  Some notation features from Booch may be inappropriate for
analysis modeling.  Items like scope and visibility seem to be
software architecture issues - best left for design.

The one other area where Booch's notation may be weak is in the
ability to develop high level views of the model.  For large systems,
it is not practical to represent a specification as a flat, huge
set of classes/objects and their interactions.  Coad/Yourdon and 
Embley, Kurtz and Woodfield are two texts that describe ways to
present a model in manageable chunks.

>
>2) Are there any case tools available (either now or in the next year) which 
>will allow you to reverse engineer Bootch diagrams from Ada code?

I think one by Mark VI (or some roman numeral) has this capability.

>
>3) How about using Coad/Yourdon for analysis and Bootch for design?  

Sure.  However, you give up some of the supposed benefits of OOA in
terms of the seamless transition to design.  A mapping between the two
notations is possible, but the terminology will change too.  In the
long run, it could be a benefit to gain a second perspective by
employing two modeling texts (since no one text is very comprehensive),
but be prepared for some project confusion.
>
>Any comments/suggestions would be greatly appreciated!
>
>Mike Mac Cormack
>Micronav International Inc
>P.O.Box 1523 / 104 Marine Drive
>Sydport Industrial Park,
>Sydney, N.S. Canada B1P 6R7
>Tel: 902-564-8833      Fax: 902-564-8764

...............................................................
|                    |   On Contract To:                      |
|     GK Khalsa      |      NCR Engineering and Manufacturing |
|....................|      16550 W. Bernardo Dr.             |
|  (619) 485-2460    |      San Diego, CA 92127               |
!....................!........................................!
!.................g.k.khalsa@sandiego.ncr.com.................!
From: dcc@dcs.ed.ac.uk (David Crooke)
Newsgroups: comp.object,cs.questions
Subject: C++ grammars
Date: 25 Jan 93 17:30:56 GMT
Organization: Department of Computer Science, University of Edinburgh

Does anyone know where I might get a c++ grammar in YACC form (and/or a C++
lexer for LEX)?

Thanks
Dave
-- 
------------------------------------------------------------------------------
David Crooke, Department of Computer Science, University of Edinburgh
Janet dcc@ed.dcs  :  Internet dcc@dcs.ed.ac.uk  :  IP talk dcc@129.215.160.2
Home: 22a Montgomery St., Edinburgh, SCOTLAND EH7 5JS.  Tel: 031 556 0265
Work: JCMB Rm 3310, King's Bldgs, W Mains Rd., Edinburgh EH9 3JZ. 031 650 6013
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.object
Subject: Re: Maintenance and OO
Date: 27 Jan 93 13:35:32 GMT
Article-I.D.: alice.24715
Organization: AT&T Bell Laboratories, Murray Hill NJ



mbk@lyapunov.ucsd.edu (Matt Kennel @ Institute For Nonlinear Science, UCSD) writes

 > I don't have that much experience with C++ except to say that I
 > think it's revolting.

This reminds me strongly of the basic structure of bigotry:

	I don't have that much experience with <<your least favorite ethnic
	or cultural group>>  except to say that I think they're revolting.

Let's try to keep discussions of programming and programming languages
technical.
From: southbay@garnet.berkeley.edu ()
Newsgroups: comp.object
Subject: U.C. Berkeley Short Courses in OO Technology
Date: 21 Jan 1993 22:56:13 GMT
Organization: University of California, Berkeley
Distribution: world
NNTP-Posting-Host: garnet.berkeley.edu

U.C. Berkeley
Continuing Education in Engineering
Announces 2 Short Courses on:

Object Oriented Software Engineering (March 1-5, 1993)

This course is designed to provide both technical and managerial personnel with
an understanding of object-oriented concepts and technology, and how its
implementation will impact software development throughout its life cycle.  The
specific problems and solutions for large software systems are discussed.

Lecturer: Ed Berard

Object Oriented Database Systems (April 19-23, 1993)

This course provides a solid grounding in object-oriented database fundamentals,
familiarity with current commercial systems and advanced prototypes, and
exposure to the most important research and development trends in the area.

Lecturers: Stanley Zdonik, Ph.D., David Maier, Ph.D., Michael Carey, Ph.D.,
Gail Mitchell, Ph.D.

For more information (complete course descriptions, outlines, instructor bios,
etc.) contact:

Harvey Stern
U.C. Berkeley Extension/Southbay
800 El Camino Real Ste. 150
Menlo Park, CA 94025
Tel: (415) 323-8141
Fax: (415) 323-1438
Newsgroups: comp.object
From: 880445p@dragon.acadiau.ca (Ravi Palepu)
Subject: Re: Non-Compatible Type Inheritance in Booch's Method?
Organization: Acadia University
Date: Sun, 24 Jan 1993 05:23:55 GMT

rmartin@thor.Rational.COM (Bob Martin) writes:

>Ravi Palepu writes:

>>Could someone shed some light on inheritance relationships that are
>>|not type compatible? (Class Diagrams from 5.2 of OOD w Apps) 

>You can get a copy of Booch's latest paper on the Notation by mailing
>a request to prod_info@rational.com

>The notation now supports the inheritance arrow in public, private and
>protected forms.

>		-----------> public inheritance

>		--|--------> protected inheritance

>		--||-------> private inheritance

>The old, "inherits (new type) relationship is now a private
>inheritance relationship.  It indicates that the inheriting class does
>not conform to the ISA relationship.  The public interface of the
>base class is not visible to clients of the subclass.  Thus, the
>subclass is a new type, rather than a type which is compatible with
>the base class....

>Although there are some good reasons for using private inheritance
>from time to time, it is usually preferable to use private
>containment.

>--
>Robert Martin       | Design Consulting    | Training courses offered:
>R. C. M. Consulting | rmartin@rational.com |  Object Oriented Analysis
>2080 Cranbrook Rd.  | Tel: (708) 918-1004  |  Object Oriented Design
>Green Oaks, Il 60048| Fax: (708) 918-1023  |  C++

Thanks to Robert and to the others who sent responses directly to me.

Is the 'new' notation becoming less general and more focused on C++?
Possibly, other types of inheritance can be mapped onto the three
described above. Smalltalk class inheritance can be mapped onto
protected inheritance (although it offers a lesser degree of encapsulation).

On the assumption that private inheritace is equivalent to C++'s private
inheritance:
I do have question, why can we say that 'inherited (new type)' relationship
is equivalent to private.  The 'inheritance (new type)' was presumably 
developed from the existence of Ada's Derived Type. Although 
the term 'inheritance' is not associated with that type, it is referred
to in Booch's book as an example of this relationship.

The Derived Type has the same interface as its base(parent). It needs a
explicit type conversion to its base.  Sub-classes derived with 
private inheritance have a different interface and they
can be implicit converted to their base class.  

I see that another relationship type might be added --!------>
(which is the case of being everything to everybody )
or a redefinition might be in order (in order to map it onto an
existing relationship type (protected seems more reasonable)). 

Any comments:
If you do have any comments, and you don't feel like replying on the net,
please do not hesitate to contact me directly.  I have started to use this
notation extensively, and I would like to incorporate any improvements. 

-Ravi Palepu

Newsgroups: comp.object
From: dave@alex.uchicago.edu (Dave Griffith)
Subject: Re: Procedures and their instances (objects in traditional OO languages)
Organization: University of Chicago
Date: Wed, 27 Jan 1993 18:22:08 GMT

In article <PCG.93Jan27160420@csthor.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>>>> On 22 Jan 93 09:52:34 GMT, davis@passy.ilog.fr (Harley Davis) said:
>
>Davis> In article <PCG.93Jan19235921@decb.aber.ac.uk> pcg@aber.ac.uk
>Davis> (Piercarlo Grandi) writes:
>
>pcg> (Bob Hathaway) said:
>
>   pcg> More precisely objects are values of a procedure instance
>   pcg> (closure/continuation) record type.
>
>   objsys> Since the FAQ will typically be for newcomers, could you
>   objsys> please put the last sentence in English and/or give
>   objsys> references?
>
>pcg> The references are easily produced: "Hierarchical Program
>pcg> Structures", in "Structured Programming", Academic Press, and
>pcg> "Structure and Interpretation of Computer Programs", MIT Press.
>
>pcg> In particular they show that (in class based OO languages) classes
>pcg> are procedures, and objects are procedure instances; closures if
>pcg> the language is a traditional OO one, and continuations if the
>pcg> language is an actor OO one.
>
>Davis> Classes and objects are not procedures;
>
>First, this is not what I wrote; I wrote:
>
>pcg> (in class based OO languages) classes are procedures, and objects
>pcg> are procedure instances

[A whole lot of extremely interesting and absolutely correct stuff deleted,
 included stuff from languages most have never even heard of.]

We seem to be having some trouble with the verb "are" here.  Bob Hathaway
seems to want it to mean "are best thought of as" and Piercarlo Grandi seems
to want it to mean "are almost always implemented as".  It would strongly 
agree with Bob the objects are _not_ best thought of as procedure instances.
Thinking of them as such introduces implementation detail too early into 
one's thinking about the object-oriented paradigm.  In many ways, this is
similar to Piercarlo's objection to the original FAQ assertion that an object
is a (record) variable.  It may often be implemented as such, but there is 
little good reason to think of them so, unless one is a language designer, 
semanticist, or (possibly) compiler writer. 

In the FAQ, objects should probably be described as they are described in 
the _introductory_ literature (Wegner, Booch, etc).  Objects are units of
encapsulation, members of classes, respond to methods, (maybe) created by
constructors, all the usual suspects.  Appending common implementation methods
as possible illustration makes sense, but making them central is likely to
make newcomers think they understand more than they actually do.

For discussion, should an introductory Pascal FAQ use the words "stack" or
"heap"?

-- 
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       dave@alex.bsd.uchicago.edu
When buying and selling are controlled by legislation, the first things bought
and sold are legislators.
Newsgroups: comp.object
From: 880445p@dragon.acadiau.ca (Ravi Palepu)
Subject: Non-Compatible Type Inheritance in Booch's Method?
Organization: Acadia University
Date: Thu, 21 Jan 1993 08:41:30 GMT

I just gave a seminar on the Booch methodolgy, and of course, someone
asked a question that I hoped nobody would. (Lesson in humility)

Could someone shed some light on inheritance relationships that are
not type compatible? (Class Diagrams from 5.2 of OOD w Apps) 

According to the book, he uses derived types in Ada as an example.
Thanks in advance.

-Ravi Palepu
Newsgroups: comp.object
From: jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
Subject: Re: active objects (was: rethinking the Object Paradigm)
    <1993Jan16.144040.12684@daimi.aau.dk> <172@eiffel.eiffel.com> 
    <1993Jan20.171936.1301@dsg.cs.tcd.ie> 
    <BUMESH.93Jan21134932@puma.cat.syr.EDU>
Reply-To: jeff@is.s.u-tokyo.ac.jp
Organization: University of Tokyo / Object Technology International
Date: Fri, 22 Jan 1993 11:44:42 GMT
X-Bytes: 1725

In article <BUMESH.93Jan21134932@puma.cat.syr.EDU> bumesh@cat.syr.EDU writes:

 >I don't see how threads really make any difference. What we really
 >should be concerned about is the mapping of activity to CPUs. Given a 
 >single CPU machine it does not make any sense to have an object which
 >can have multiple threads at all. You could easily have a model in
 >which we have multiple threads per object but this does not result in
 >tru concurrency. 

Who cares about CPUs?!  They come and go.  We get more or less.
Architectures change...  The important part from a programming/design
point of view is the model of concurrency.  Yes, in some places it is
important to know how it will actually run but I believe that these
are relatively isolated.  Often multiprocessor systems are developed
on uniprocessors and then run on multiprocessors.  Its the presence of
a model that allows this to happen.

As far as multi-threaded goes; I have never really been sure that I
understood the concept.  Are Smalltalk objects multithreaded?  I can
have two ST processes (threads) concurrently "executing" the same
object at the same time.  Is that it?

 >Ciaran> Does anybody have a definitive definition of what "active" means?
 >Ciaran> Failing that, what are the different definitions which the other
 >Ciaran> participants are using?
 >
 >Active should essentially mean the ability to perform computation.

Does "Perform computation autonomously (i.e. with its own logical or
physical processing resources)" fit well with you?  That's pretty much
what I mean when I say "active".

--
ato de, |m        -- "Throughout my life I have sought peace and quiet"
                                                          - Ted Nuggent
Newsgroups: comp.object,comp.lang.c++,comp.ms-windows.programmer.tools
From: currie@teal.csn.org (Andrew Currie)
Subject: Seeking feedback on Portable GUI Tools based on Experience
Followup-To: currie@csn.org
Keywords: portable GUI, software engineering
Organization: Colorado SuperNet, Inc.
Date: Fri, 22 Jan 1993 14:48:25 GMT

Greetings,
If you have _any_ development experience with _any_ of the currently
available portable GUI tools i would really like to hear from you.
I must make a choice between such tools as: XVT, Zinc, zApp, StarView,
C++/Views, CommonView, etc. and would like to base this on more than
sales literature, simple demo apps, and magazine reviews.

Any feedback at all would be greatly appreciated. Please e-mail me at
currie@csn.org or call (collect) 303-938-8650. If there is interest
i will summarize my evaluation process (and these comments) and make
the results available to all interested developers.

thanks for your time,

Andrew Currie
 


-- 
+++++++++++++++++++++++
currie@csn.org
+++++++++++++++++++++++
Newsgroups: comp.object
From: paul@melody.Rational.com (Paul Jasper)
Subject: Re: Booch question: new class relationship?
Reply-To: paul@rational.com
Organization: Rational
Date: Thu, 28 Jan 1993 20:49:28 GMT

In article <rmartin.727740331@thor>, rmartin@Rational.COM (Bob Martin) writes:
> hartman@ulogic.UUCP (Richard M. Hartman) writes:
> 
> You can mail a letter to prod_info@rational.com asking them for
> Booch's latest paper on the notation.  In that paper you will find
> what you are looking for. 

This is now available by e-mail in PostScript form, from the same address
(or phone 1-800-ROSE-237).

> Containment by value represents the notion that the storage of the
> contained class exists within the storage of the containing class.
> The containing class has intrinsic knowledge of the contained class
> (ie. knows where to find it).  The contained class is created and
> destroyed with the containing class.  

Yes, this is correct, but then you add:

> The contained class cannot be polymorphic.

Tut, tut, Bob!  You should know this ;^)

"Has by value" doesn't necessarily imply physical containment.  The
"intrinsic knowledge" may still be a pointer or even a database reference,
but the semantics will still be that instances of the sub-class are 
created and destroyed with the parent object.  

Hence, polymorphism is perfectly acceptable.  In fact, it is used quite
frequently.  For example, in designing a tree, you might have an abstract
base class representing a node.  The child nodes can be represented by a
circular "has by value" relationship back to itself (er, "reflexive"?).
Obviously, this can't be implemented by physical containment.  Concrete
sub-classes inheriting from the node class can then be defined for each 
of the types of data to be stored in the tree, for example, to allow
mixed trees of strings, integers and reals with polymorphic behavior.

> 
> 	class ContainingByValue
> 	{
> 	  Contained x;
          // or Contained *x;
> 	};

class ContainingByValue
{
    ContainingByValue **children;
};

class ContainingByValueString: ContainingByValue
{
    char *data;
};

-- 
-- Paul Jasper
-- RATIONAL
-- Object-Oriented Products
--
Xref: sparky comp.object:5063 comp.lang.c++:19932 comp.lang.c:20232 comp.lang.clos:1082
From: ggolden@msen.com (Glenn R. Golden)
Newsgroups: comp.object,comp.lang.c++,comp.lang.c,comp.lang.clos
Subject: Re: CORBA DII Implementation (CLOS & C) - Anonymous FTP Site
Followup-To: comp.object,comp.lang.c++,comp.lang.c,comp.lang.clos
Date: 27 Jan 1993 03:17:04 GMT
Organization: Msen, Inc. -- Ann Arbor, Michigan
NNTP-Posting-Host: garnet.msen.com
X-Newsreader: TIN [version 1.1 PL8]

I would also like an OMG newsgroup:  I usually look for information
about OMG activities in comp.object.

- Glenn R. Golden  |  Global Architect @ Comshare, Inc. |  Ann Arbor, MI, USA.
  (home) ggolden@msen.com   (work) ggolden@comshare.com
From: VAAGA@gribb.hsr.no (Vaaga, Hans Egil       7-93)
Subject: Microsoft C/C++ Programming by Steve Holzner. C++ Books.
Organization: Rogaland University Centre
Date: Thu, 28 Jan 1993 11:06:48 GMT

Hello!

I'm going to buy a C++ book. Could anybody tell me what I should buy?

I'm going to devolope a C++ program in the Microsoft Windows enviroment,
so I wonder if the book Microsoft C/C++ Programming by Steve Holzner is
a good choice. 


Hans Egil Vaaga
Rogaland University Centre
vaaga@gribb.hsr.no
Newsgroups: comp.object
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Booch question: new class relationship?
Organization: Rational
Date: Fri, 29 Jan 1993 00:44:45 GMT

LANG@nvdv.e-technik.uni-stuttgart.dbp.de (MARTIN LANG) writes:


|> 	Contains by Value
|>                 *=========#
|> 
|> 	Contains by Reference
|>                 *=========[]
|> 
|> 	Uses
|> 		O=============


|Which class relationship is appropriate if you have two relations at the
|same time, e.g.

|class ValueAndUse {
|  void AddValue(Value & val);
|  
|  Value X;
|};
| 

It is perfectly fair to put both relationships on a a diagram.
Typically however each relationship would appear on a different class
diagram since each relationship represents a different aspect of the
class.

This is an important point.  In Booch notation you do not try to
completely document a class in a single diagram.  You try to convey a
single idea in each diagram.  It may take many diagrams, both object
and class digrams to completely describe the class.

This is why you should also keep Booch's templates (or some other
record like a CRC card or even in incomplete software description like
a class header in C++).  The diagrams are meant for showing concepts
not completeness.  This makes the diagrams easy to create and easy to
follow.


--
Robert Martin       | Design Consulting    | Training courses offered:
R. C. M. Consulting | rmartin@rational.com |  Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004  |  Object Oriented Design
Green Oaks, Il 60048| Fax: (708) 918-1023  |  C++
Newsgroups: comp.object