HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.object,comp.lang.clos
Subject: Re: Beginner's Question - CLOS
Date: 19 Aug 1992 18:12:09 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <graham.714230337@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>Now to CLOS. The above comment would suggest that CLOS does not do
>things in the objects-that-know-how-to flavour. If this is so the
>only sort of alternative I can think of (not knowing CLOS) is to
>have objects that are defined by some sort of record structure, where
>each slot can be a function. 

No, that's how objects-that-know-how-to are usually implemented.

CLOS is based on generic functions, rather than messages to objects.  You
then define the specific implementation of a generic function for a given
tuple of argument types.  For instance, an I/O system might have:

(defmethod display ((value real) (destination window))
  ... ;; code to display a real number graphically on a window
  )

(defmethod display ((value integer) (destination terminal))
  ... ;; code to display an integer textually on a terminal
  )

(defmethod display ((value float) (destination terminal))
  ... ;; code to display a floating point number textually on a terminal
  )

>			      I presume that a function can take an
>argument of type X or any sub-type of X. How is this subtyping specified.
>(note: I appreciate that I am using sub-type in a very sloppy sense
>here but I think it is obvious what I mean here). Is this indeed what 
>CLOS does? 

Class definitions in CLOS are very similar to that of most other OO
languages with multiple inheritance.  Subclasses inherit the slots of the
superclasses.  Any methods defined for a superclass are also defined for
the subclass, but it can override them (there are also ways to tell the
system to run all the methods automatically in various ways).

>	    If so how are sub-types specificied. I would be
>interested in seeing a specification for say a stack in CLOS (any
>takers out there). 

Just saying "a specification for a stack" isn't very meaningful.  OO
programming is all about the relationship among similar types of objects,
so an example with just one type wouldn't show much.

Perhaps someone else out there has some simple CLOS examples.  The general
problem I find with CLOS examples is that OO programming doesn't really
show its utility unless the application is complex.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Xref: sparky comp.object:3194 comp.software-eng:3190
From: howard@Redwood.XAIT.Xerox.COM (Howard Bernstein)
Newsgroups: comp.object,comp.software-eng
Subject: Request for info:  Using Booch notation for OOA
Keywords: OOA, Booch, Function Points
Date: 12 Aug 92 14:14:46 GMT
Reply-To: howard@Redwood.XAIT.Xerox.COM (Howard Bernstein)
Organization: Xerox Advanced Information Technology, Cambridge, MA

The title says it all.  We've recently purchased a design tool called
"Rose" which supports the Booch notation.  We would like to apply this tool
in OOA as well.  Any information (papers, articles, etc.) on using the
Booch notation in OOA would be appreciated.

On another note, if anyone has experience with Function Point counting on
OO projects...  any information in this are would also be greatly
appreciated.

Thanks in advance!

-- 
-------------------------------------------------------------------------------
Howard Bernstein        Xerox Advanced Information Technology    (617) 499-4402
howard@XAIT.Xerox.com  4 Cambridge Center, Cambridge, MA 02142    FAX  499-4409
-------------------------------------------------------------------------------
Newsgroups: comp.object
From: jtruitt@dw3f.ess.harris.com (Jim Truitt)
Subject: second attempt-- Archive for comp.object
Reply-To: jtruitt@dw3f.ess.harris.com (Jim Truitt)
Organization: Harris GISD
Date: Fri, 21 Aug 1992 13:10:58 GMT

Hello again,

	I posted once before, looking for an archive site for this newsgroup
with ftp anonymous
access.  The only responses I received were of the sort, "If you find
out let me know."

	I have located small pieces of archived articles from comp.object, but
still can't find a 
full archive.

	If you know the secret please post to this newsgroup or email me directly.

	Also, I've seen some references to a FAQ for comp.object, but I've
never located one.
Anyone who has insight into the status of a an FAQ for comp.object,
please make it known.

Thanks
Jim Truitt

--
-------------------------------------------------------------------------------
| NAME	:JAMES O. TRUITT (JIM)		| HARRIS CORPORATION	| INFORMATION |
| PHONE	:1-407-984-5791			| P. O. BOX 98000	|   SYSTEMS   |
| FAX	:1-407-984-6323			| MELBOURNE, FL 32902	|  DIVISION   |
| EMAIL	:HARRIS.JTRUITT@IC1D.HARRIS.COM	|			|             |	
-------------------------------------------------------------------------------
Xref: sparky comp.object:3281 comp.lang.ada:2395 comp.lang.c++:12677
From: wellerd@ajpo.sei.cmu.edu (David Weller)
Newsgroups: comp.object,comp.lang.ada,comp.lang.c++
Subject: Re: Info sought on method and life cycle model
Date: 20 Aug 92 23:10:43 GMT
Organization: Ada Joint Program Office

In article <1992Aug20.223539.676@sei.cmu.edu> progers@ajpo.sei.cmu.edu (Pat Rogers) writes:
>
>A large NASA simulation project is considering moving to Ada
>using a Booch-Rumbah-Coad OOD method and the spiral life
>cycle model.  On behalf of the sustaining engineering
>organization, I am soliciting references or first hand
>experiences on maintaining Ada software for similar projects
>(large, complex, aerospace applications), experiences with
>the spiral life cycle model (I'll take information from any
>project, as I do not think there are that many), and
>maintenance of translated code (I've got information on
>whether or not to translate, but if it is decided that
>translation is the way to go, information on the long-term
>effects, based on experiences, would be of use).
>
>Don't reply directly to this note unless the address that follows
>does not work:
>                 kathy@ghg.hou.tx.us
>
I would like to ask that you cc to my address also, since I share
Kathy interests (Don't I, Kathy?)
My address is:
	wellerd@ajpo.sei.cmu.edu

Thank you
Dave Weller
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M() versus M(O) notation
Date: Tue, 18 Aug 92 03:30:19 GMT
Organization: Object Systems

In article <DOUG.92Aug16200024@monet.ads.com>, doug@monet.ads.com (Doug Morgan) writes:
>   because the notation strongly influences thought processes and actually
>   constrains them (cfr. Dijkstra on BASIC), and that in particular the
>   'O.M(...)' notation by making 'O' visually special suggests that
>   overloading should happen only on the first argument, which is most
>   probably a misleading impression, as overloading resolution ought to be
>   symmetrical, which is the most "natural" thing.
>
>This issue may finally boil down to genetic predispositions and
>environment influences.  Some people just see M(O1,O2,...) as fitting
>so beautifully into their notions of mathematics, symmetry, Occam's
>razor, etc.  that no other notation makes an iota of sense.  Others
>just see O1.M(O2,...) as the high point of the new OO-think of
>encapsulation, message passing, classes, etc.  Neither group accepts
>the the other's view and compromise is out of the question.  (Oh, by
>the way, the TRUTH is that the first group is completely correct and
>the second is completely misguided.)

Ah, an old subject of interest of mine.  Why not simply examine the
underlying grammar from which these constructs came (which is imperative)
and then reevaluate them?  The true and quite natural origin from whence
they came doesn't seem to be mentioned much anymore.

bob
objsys@netcom.com
Newsgroups: comp.object
From: mat@mole-end.matawan.nj.us
Subject: Re: Class methods (was: Re: How to design a data structure library)
Summary: Spelling correction--to my OWN article, so no flames!
Organization: :
Date: Wed, 12 Aug 1992 15:46:29 GMT

In article <1992Aug11.180111.4658@mole-end.matawan.nj.us>, mat@mole-end.matawan.nj.us writes:

> We have here a `relationship' that is also a transaction or process of
> some sort.  May I suggest the term `termporality' ?
				      ^^^^^^^^^^^^ temporality
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Xref: sparky comp.object:3209 comp.software-eng:3226
From: copeland@pioneer.arc.nasa.gov (Kimberly Copeland RCA)
Newsgroups: comp.object,comp.software-eng
Subject: Re:Comp.objects archive site
Date: 14 Aug 92 23:34:30 GMT
Organization: NASA Ames Res. Ctr. Mtn Vw CA 94035

Is this news group being archived somewhere?  If so, where?

Please reply to copeland@pioneer.arc.nasa.gov.  Thanks
K. Copeland
E-mail ames::"copeland@pioneer.arc.nasa.gov"
phone: (415) 604-6312 or (415)465-5390
P.O. Box 10923
Oakland, Ca 94610
Newsgroups: comp.object,comp.software-eng
From: lynnmar@bgtys20.uucp (Lynn Marshall)
Subject: OOPSLA Workshop on OO Team Design
Reply-To: lynnmar@bgtys20.UUCP (Lynn Marshall)
Organization: Bell-Northern Research, Ottawa, Canada
Date: Thu, 20 Aug 92 20:19:07 GMT

RE:  OOPSLA Workshop on OO Team Design:   October 18/92
======================================

We have received a number of inquiries whether submissions would be
accepted later than the posted August 15th deadline...the answer is YES!

Please submit you position paper by early September.
The workshop is described below...





Team Approaches to OO Design
----------------------------


Large complex real-time systems may be developed by design teams
using object-oriented analysis and design methodologies.  This workshop
will focus on the processes and representations used to create and
manipulate OO designs.  The context might be that of an OO system
(e.g. implemented in Smalltalk or C++) or that of a system with a large
legacy of non-OO designs and code.

Position papers should indicate participants' experience with OO design
techniques, the size of their current system (design/code bulk and team
size), their design tools, and design process.  Please include brief
statements that respond to the following questions:

  - What is your vision of OO design?  What are the essential components
    of an OO design (process) in the context of your environment?
  - What factors make OO analysis and design effective/ineffective in
    your design environment?
  - What intermediate goals are required to move from your current
    process/environment to your vision of OO design?

The workshop will offer a forum for practitioners to exchange ideas and
develop a consensus on team OO design.  If the results of the workshop
warrant, selected contributions and/or a summary report will be submitted
to an appropriate publication.

Position papers (500-1500 words/2-5 pages) should be submitted by E-Mail
(preferably in Ascii or Latex format).  Please include a brief
biography at the end of your position paper and send it to:

Steven D. Fraser                            E-Mail:  sdfraser@bnr.ca
Bell-Northern Research Ltd.,                Fax:     (613) 763-4222
Software Engineering Center,                Office:  (613) 763-3073
P.O. Box 3511, Station C,
Ottawa, Ontario, Canada.  K1Y 4H7
From: orpheus@reed.edu (P. Hawthorne)
Newsgroups: comp.object
Subject: A Graph Theory Newsgroup, Perhaps?
Date: 18 Aug 92 08:53:37 GMT
Article-I.D.: reed.1992Aug18.085337.27510
Organization: Reed College, Portland OR


  Graph theory is at the heart of so many fields that it is somewhat
obscured by its own versatility.

  I feel that there ought to be a graph theoretic newsgroup, if only for
the insights that such a multidisciplinary newsgroup could offer.

  I'd be interested in hearing from others, to see if a more formal
approach to creating such a newsgroup is warranted.


  Theus (Prometheus Hawthorne - Jones, orpheus@reed.edu)
From: Mikael Bohlin <mb@cadcam.kth.se>
Subject: OOA-tool
X-Xxdate: Thu, 20 Aug 92 17:40:14 GMT
Organization: IVF-KTH Manufacturing Systems
X-Useragent: Nuntius v1.1.1d7
Date: Thu, 20 Aug 1992 15:39:12 GMT

Hi there!

I would like get information about any tools supporting OOA/OOD for Mac.
Preferable free or shareware. Any info will do. Answer by email.

Thank you for your time.

Mikael Bohlin
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Fri, 21 Aug 1992 14:06:58 GMT
Subject: O.M(...) vs M(...), and is the Real World O-O?
Organization: Hewlett-Packard Laboratories, Bristol, UK.
From: progers@ajpo.sei.cmu.edu (Pat Rogers)
Subject: Info sought on method and life cycle model
Organization: Software Engineering Institute
Date: Thu, 20 Aug 1992 22:35:39 GMT


A large NASA simulation project is considering moving to Ada
using a Booch-Rumbah-Coad OOD method and the spiral life
cycle model.  On behalf of the sustaining engineering
organization, I am soliciting references or first hand
experiences on maintaining Ada software for similar projects
(large, complex, aerospace applications), experiences with
the spiral life cycle model (I'll take information from any
project, as I do not think there are that many), and
maintenance of translated code (I've got information on
whether or not to translate, but if it is decided that
translation is the way to go, information on the long-term
effects, based on experiences, would be of use).

Don't reply directly to this note unless the address that follows
does not work:
                 kathy@ghg.hou.tx.us

You can reach me in person at (713) 488-8806 or by fax (713)
488-1838.

Thanks in advance,
Kathy Rogers
(recently moved to GHG Corporation)
From: bytor@grumpy.bellcore.com (Ross Huitt)
Subject: Re: OO Software Metrics: beyond lines of code
Keywords: OO metrics
Organization: Bellcore
Distribution: comp.object
Date: Wed, 12 Aug 92 15:14:13 GMT

In article <RHARMON.92Aug11164255@triton.srg> you write:

|> We are having problems establishing metrics for our software environment.  

You are part of a very large club!

|> Some of the current proposals are:
|>    Lines of code - Most everyone here think LOC is outdated by OO techniques.

LOC is too ambiguous. If you need a measure of the raw size of the executable portion of your code,
you are much better off with counting the number of executable statements (if its C++) as defined
in the language grammar (see Chapter 6 of the ARM for C++). I only use
LOC for historical comparison against C systems for which I have no other data.

|>    McCabe and Halstead numbers 

I don't have a problem with McCabe's. Halstead I can do without.

|>    Amount of Code Reuse - This sounds good.
|>        one measurement could be:
|>           (number of application classes) / (number of tools classes)
|>           or
|>           (number of referenced classes including tools) /
|>                                             (number of tools classes)

Reuse metrics will be essential. But there are different kinds of reuse. You'll need different
metrics for each kind.

|> 
|> Apart from these, we cannot seem to come up with any other ideas.
|> Is anyone doing research in this area?

Me, for one. Also check out these two refs (ones that I have handy):
Chidamber, S.R., and Kermerer, C.F., "Towards a Metrics Suite for Object-Oriented Design",OOPSLA '91
   Conference Proceedings
Rajaraman, C., Lyu, M.R., "Some Coupling Measures for C++ Programs", The TOOLS'92 Conference Proceedings.

|> Do any Metrics tools exist for C++?

I imagine some environment vendors (Procase, Centerline, ObjectCenter) will be offering some
metrics support in their tools in the near future, but I haven't heard anything. I have heard
of PC-Metric from SEI labs and CodeCheck from Abraxas. I cannot (legally) say anything qualitative
about these two products, though. 

I'm just wrapping up a prototype C++ metrics tool. We cover most of the Chidamber metrics,
a few standard metrics, and a few of our own. I got some _real_ interesting numbers from
an earlier version that I'll post one of these days....


|> rharmon@srg.uunet.uu.net        |
|> Robert B. Harmon ms:5-230       |  This space is left intentionally blank.
|> Arinc Research 2551 Riva Rd.    |  
|> Annapolis, Md 21401             | 


Hope this helps....

Ross Huitt
bytor@ctt.bellcore.com
Note: any mention of a commerical vendor or product is meant for illustrative purposes only and 
does not imply any kind of implicit or explicit endorsement.

Newsgroups: comp.object
From: br707@cleveland.Freenet.Edu (Mike L. Melamed)
Subject: Help on TVision Help.
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Sun, 16 Aug 92 17:52:59 GMT


Could someone provide me with a small example of using HELP in TurboVision
TP6.0?


Would really appriciate it...


####
1
Wops


-- 
Newsgroups: comp.object
From: neff@mandor.metaphor.com (Randall Neff)
Newsgroups: comp.object
Subject: Re: OO Software Metrics: beyond lines of code
Date: 14 Aug 92 16:15:51 GMT
Distribution: comp.object
Organization: Metaphor Computer Systems, Mountain View, CA


Two Ignored Research Topics:   
	(Watch out for people proposing software metrics unless they 
	personally write large programs.)


1.  There needs to be a metric that measures the quality/completeness of the
documentation:
	Every method has its pre-conditions and post-conditions listed. 
	    Does the method change the object's internal state?
	Every parameter to every method has ranges listed (what about null
	    pointers?).
	Every method has its exceptional behavior listed, its error conditions
	   and what it does about them.
	Every method has a O() performance function.
	Every method describes any memory allocation (how many bytes) and
	   memory deallocation.  (This is very tricky with reference counted
	   objects).
	Every object with internal state has invariants listed.
	The size of an object in bytes is listed (or a formula, watch out for
	   what malloc really does in terms of allocation).
	Every class has a complete list of all (ALL!) methods that it supports,
	   identifying which parent class each method is inherited from. This
	   is extremely important for multiple inheritence.
        

2.  There needs to be a metric on uniformity of methods (ie every class has
	a required set of methods):
	The class of every object can be determined at run time.
	Every object can print (or write/read to a file) its contents.
	The correctness of the contents of an object can be checked.
	Each object has deep and shallow copy, deep and shallow equality.
	It is possible to enumerate over all objects of a class.


Randall Neff, Ph.D.
(Personal opinion, not those of Metaphor.)

Newsgroups: comp.object
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: O.M() versus M(O) notation
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 21 Aug 1992 02:55:30 GMT

pcg@aber.ac.uk (Piercarlo Grandi) writes:

>So, here you seem to be saying that abstract classes in most OO
>languages are a considerable mess, because they *ought* to be used as a
>poor man's template facility, and then end up being used as a poor man's
>interface definition facility too.

No, that is not what I am saying.  They are a good template facility.
They are all the template facility that Smalltalk needs.  C++ needs
"templates" in addition to abstract classes, so they are perhaps not
as good for languages with static type checking.  They are not a good
interface definition facility, it is true.  Or, even if it isn't true,
I believe it!

>Which is exactly about my point, incidentally. Why not separate
>interface defining, generic defining, and class assembling into three
>separate facilities? Then your 'abstract classes' would have no reason
>to exist, and inheritance as well.

Lots of people, including me, have argued for a long time that interface
defining and class assembling should be separate facilities.  I call the
relationship between interfaces subtyping, and the relationship between
classes subclassing.  You are not going to get rid of inheritance, you
are just going to call it by a different name.  Moreover, you are not
going to get rid of abstract classes, either.  Abstract classes are an
important design technique.  Abstract classes are more powerful than
templates because you can do more than just fill in the missing 
operations, you can also redefine the operations that are provided.
Thus, the provided operations all become defaults that a new subclass
can replace with a more efficient version.

Ralph Johnson -- University of Illinois at Urbana-Champaign



Newsgroups: comp.object
From: goodsenj@ajpo.sei.cmu.edu (John Goodsen)
Subject: Re: O.M() versus M(O) notation
Organization: Ada Joint Program Office
Date: Sat, 15 Aug 1992 21:53:15 GMT

>
> Bertrand Meyer is probably the chief opponent to this
>view.  He says that one of the chief advantages of OOP is that it
>*combines* interfaces with code, and that people who try to seperate
>them are making a mistake.  Thus, it would be a mistake to think that
>there is a concensus on this issue.
>

Could you point us to where BM has stated this?  I'm finding
it hard to believe that a sane person would make such a claim,
and assuming sane people have made this claim, I'm uinterested to 
understand the reasoning behind it....

-john

John Goodsen
goodsenj@ajpo.sei.cmu.edu


-- 
John Goodsen                   (619) 530-0881
The Dalmatian Group            U.S. PCIS Expert Review Team
User Interface Specialists     Ada Joint Program Office
jgg@dalmatian.com              goodsenj@ajpo.sei.cmu.edu
From: burandt@ira.uka.de (Axel Burandt)
Newsgroups: comp.object
Subject: papers wanted
Keywords: semantics logical-calculi
Date: 20 Aug 92 14:22:03 GMT
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: i11s14.ira.uka.de



Hi,

I would like to obtain some papers about the following topics:

 - denotational semantics of object-oriented languages

 - logical calculi for the verification of OOL

 - general approaches to the semantics of OOL

Please send the references to the following e-mail adress:

  burandt@ira.uka.de

Thanks a lot!

Axel Burandt
Newsgroups: comp.object