HDTenEightyP/NetNews huggingface dataset:
From: neubert@cuphub.cup.edu
Newsgroups: comp.object
Subject: Re: New book: NeXTSTEP Programming - Object-Oriented Applications
Date: 15 Dec 92 11:56:47 GMT
Organization: California University of Pennsylvania, California, PA

In article <6002@rosie.NeXT.COM>, Conrad_Geiger@NeXT.com (Conrad Geiger - Manager, International NeXT User Groups) writes:
> Hello,
> 
> Has anyone seen or read this new book?
> 
> conrad
> International NeXT User Groups
> 

Nice plug (for NeXT), Conrad.  Stevo must be expecting everyone at
NeXt to plug as much as he does at keynote/closing event speeches
that turn into nothing more than an overblown sales pitches.

John Neubert

> ___________________________________________________________________
> NeXTSTEP Programming - STEP ONE: Object-Oriented Applications
> Simson L. Garfinkel and Michael K. Mahoney
> Price: $39.95
> Hardbound, 664 pages, includes DOS diskette
> ISBN: 0-387-97884-4
> 
> 
> This book is about programming computers that run NeXTSTEP. It is
> a no-nonsense, hands-on book that teaches programmers how to write
> application programs that take full advantage of NeXTSTEP. This
> book is the first comprehensive work dealing with the 3.0 version
> of NeXTSTEP. The floppy disk contains the complete source code for
> all programs in the book and a tutorial for Interface Builder.
> 
> Simson Garfinkel is Senior Editor at NeXTWORLD Magazine and an
> experienced NeXTSTEP developer. Michael Mahoney is Professor and
> Chair of the Computer Engineering and Computer Science Department
> at California State University, Long Beach, and is president of
> the Southern California NeXTSTEP Users Group (SCaN).
> 
> TO ORDER
> 
> Call toll free 1-800-SPRINGER (1-800-777-4643)
> 8:30 a.m. to 5:30 p.m. (EST)
> Credit Cards Accepted: American Express, MasterCard, Visa, Discover.
> 
> In New Jersey: Call (201) 348-4033
> Purchase Orders To: Springer-Verlag New York, Inc., 44 Hartz Way,
> Secaucus, NJ 07096
> 
> Fax Purchase Orders To: (201) 348-4505
> NY, NJ, MA, VT, and CA residents should include applicable sales tax.
> Canadian residents should include 7% GST.
> Shipping: Add $2.50 for the first book; $1.00 for subsequent books.
> Foreign Airmail Orders: Add $10.00 per book.
> 
> All orders are processed upon receipt. Prices quoted are payable in
> U.S. currency.
> 
> 
> For information on bulk sales, please contact Thomas Heitzman at
> (212) 460-1675.
> 
> For information on 30-day examination copies for course adoption,
> please contact Lilliana Sierra at (201) 348-4033 ext. 322.
Newsgroups: comp.object
From: "william cochrane" <william.cochrane@canrem.com>
Subject: banking software (prefera
Reply-To: "william cochrane" <william.cochrane@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 13 Dec 92 12:27:13 EST

I cannot identify specific packages, but I can identify sources of
information which may help.

Most application vendors work with computer hardware vendors.  These
vendors have catalogues of package developers by industry vertical, so I
would try local IBM, DEC, HP, NCR, UNISYS, and SUN sales offices, and
ask for financial services catalogues.

Look in Wall Street Computer Review magazine, especially look fo a
annual package issue.

Datapro publishes Binders of Application packages by industry vertical.
This may be library or at vendor office.  Consultants amy have as well.

There is an European (British) publication called Banking Automation(?)
which would also list packages.  If any of the publications have a
feature article on OOPS, they will probably talk about some application
apckages.

hope this helps.
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.object
From: bhc@dirac.i-kinetics.com (Bruce Cottman)
Subject: Re: Object Request Broker 
Organization: I-Kinetics, Inc., Cambridge, MA USA
Date: Sun, 13 Dec 1992 18:08:55 GMT


 OMG CORBA spec can be captured from:

    Richard Mark Soley, Ph.D., Vice President, Technical Director
    Object Management Group
    Framingham Corporate Center
    492 Old Connecticut Path
    Framingham, MA  01701
    (508) 820-4300   fax:  (508) 820-4303   email:  soley@omg.org
    omg_server@omg.org

I would try the omg_server@omg.org first with a mail request for the spec.
From: johnson@cs.uiuc.edu (Ralph Johnson)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Date: 20 Dec 92 21:45:54 GMT
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

dave@alex.uchicago.edu (Dave Griffith) writes:

>>>But most languages have no way to _enforce_ the requirement that they "only
>>>allow operations that are in line with their essential sameness".  

I then argued that most languages have no way of enforcing most interesting
things.  In particular, I said:

>>We can't really enforce that a subclass provides the same behavior
>>as a superclass.

Dave Griffith replied:

>Eiffel (with the exclusion of a few egregious features like
>"undefine") can and does enforce that a subclass has the same behavior as
>a superclass.

This is a common misconception.  I'm a fan of Eiffel, and I applaud the
attempt to put more design information in programs by using assertions and
invariants, but there is still a lot of interesting behavior (in fact,
most interesting behavior) that can't be specified.  Reusing an earlier
example, try specifying that equality is symmetric, reflexive, transitive, 
and substitutabilty of equals for equals should hold in all cases. I think
that symmetry should be easy to specify.  Reflexivity and transitivity
are usually easy to prove, but I don't think you can express them in Eiffel,
since it doesn't have a "for all" construct.  Probably you can enforce
reflexivity by stating that an object is equal with itself whenever you
create a new object.  I don't have any idea about transitivity, nor about
substitutability of equals for equals.

If it turns out that there is a way to express that in Eiffel, how about
my example of requiring that a function used by a sorter provide
a total ordering on the collection to be sorted.  I guess you could
do this for any particular finite collection by checking all triples.
However, I don't think Eiffel allows loops in assertions.

It is not hard to make an assertion language that is more
powerful than the one in Eiffel.  However, it would then
become much more expensive to check.

Getting back to objects vs. values, I agree that reasoning about 
side effects is important.  Promising approaches are Gifford's
"effects" system that was described in a POPL'88 (and other places
that I forget) and Hogg's "Islands" that was described in OOPSLA '91.
I'm just not convinced that making a hard and fast distinction 
between objects and values is necessarily a good idea.

-Ralph Johnson
Newsgroups: comp.object
From: trix@cbnewsm.cb.att.com (t.roger.kiang)
Subject: Re: OOA&D Methodologies
Organization: AT&T
Date: Fri, 18 Dec 1992 23:23:57 GMT

>Another topic I would like to bring up is CASE tools-- especially OO
>CASE tools.  So far I am not very impressed but I would buy any CASE
>tool that allows me to annotate any diagram artifact (this is critical
>to capturing the HOW and WHY of your analysis and design so that you
>do not forget and so others can step into your mind).
>
>Thanks for listening.
>
>Jim O'Hearn,
>Software Engineer
>Beckman Instruments Inc., Diagnostic Systems Group

IDE has a C++ CASE tool which costs an arm and a leg.
Have anyone used it in actual software development.
Was it useful?  Their demo was impressive, but...


Roger Kiang
trix@edsel.att.com
Newsgroups: comp.object
From: henley@eng.auburn.edu (James Paul Henley)
Subject: Re: Is Borland the leader in technology?
Organization: Auburn University Engineering
Date: Wed, 16 Dec 1992 17:42:34 GMT

In article <BzBMIq.AHB@cs.uiuc.edu> johnson@cs.uiuc.edu (Ralph Johnson) writes:
>
>One thing that software engineers have a lot of experience with is being
>thrown on projects and having to learn new fields and build systems that
>are completely new to them.  We have learned that there is no substitute
>to learning the problem domain, that if you don't know the problem domain
>then you will end up working on the wrong problems to solve.  It takes a
>lot of hard work and lots of communication to figure out the right problems
>to solve and figure out how to build the right systems.  People who want
>quick fixes are usually headed for trouble.
>
>Now, none of us know the problems you are trying to solve.  I don't
>understand what you want.  However, when I see you write that you expect
>people to communicate primarily by tossing pieces of code back and forth, 
>I expect you are not likely to be successful.
>
>Why are you posting to this newsgroup?  What it is that you are looking
>for?  This is not a crank comment; I'd like to know.
>
>-Ralph Johnson

I have tried to give a sample of the type of problem that I am trying to
solve.  I tried not to go into too many details online, but I will gladly
fill you in on the details by email.  You will find, however, that the 
problem description gets quite long when you get down to the minute details
that have to be considered.   I certainly don't *expect* people to 
communicate by tossing around pieces of code, I am simply telling you how
it *is* done.  If you like, I can give a problem statement, and a piece of
code, and let you decide which makes more sense to you. 

Dr. James P. Henley Jr.
Department of Chemical Engineering
Auburn University

Newsgroups: comp.object
From: janzen@lichen.mpr.ca (Martin Janzen)
Subject: Re: C++ tools recommendations wanted
Reply-To: janzen@mprgate.mpr.ca
Organization: MPR Teltech Ltd.
Date: Thu, 17 Dec 92 21:37:30 GMT

In article <7623@fury.BOEING.COM>, cek@sdc.boeing.com (Conrad Kimball) writes:
>[wants suggestions for C++ software development tools]

>How about GUI builders, such as UIM/X?  There are quite a few competing
>products for use in building C applications, but how well do they work
>in a C++ environment?

I've used UIM/X, but find that I prefer X.Designer (from Imperial Software
Technology, sales@ist.co.uk; or V.I. Corp., info@vicorp.com), because of
its widget tree editor, layout editor, and numerous other small details
not really relevant to comp.object...

X.Designer generates code that contains one global variable for each widget
to which you assign a variable name.  I create one class for each interface
(ie. each separate Shell widget and child widget tree).  The constructor
calls the XD-generated function, then copies the global variables to
private data members.  This encapsulates the interface nicely, and makes
it easy to create multiple instances of the interface.  (I do have to
filter the generated code through a sed script; I'd be happy to mail you
the script if you end up using X.Designer.)

>What about Motif toolkits for use with C++?  C++ wrappers around the
>OSF Motif toolkit?  Native C++ toolkits that deliver Motif look and
>feel?

The problem with C++ wrappers like WWL is that a) they prevent you from
using a UI builder, and b) you're dealing with a lot of very small classes,
corresponding to individual widgets.  Some people may prefer this; I've
found it easier to use something similar to Doug Young's approach (see his
book "Object-Oriented Programming with C++ and OSF/Motif", Prentice-Hall,
1992, 0-13-630252-1), in which each class corresponds to a higher-level
abstraction within the program (such as an entire interface), encapsul-
ating a _group_ of related widgets, and all associated callbacks, actions,
member functions, and so on.

I haven't tried any of the native C++ toolkits like InterViews or OI (or
whatever ParcPlace calls it now).

Hope that helps...

-- 
Martin Janzen                     janzen@mprgate.mpr.ca (134.87.131.13)
MPR Teltech Ltd.                  Phone: (604) 293-5309
8999 Nelson Way                   Fax: (604) 293-6100
Burnaby, BC, CANADA  V5A 4B5
Newsgroups: comp.object
From: ulf@julius.c3consult.comm.se (Ulf Lagerstedt)
Subject: Inventory of methods for software development
Organization: Communicator C3Consult AB
Distribution: comp
Date: Thu, 17 Dec 1992 16:39:40 GMT



 (I asked this a while ago in comp.software.eng, with limited success.
 If the subject is slightly inappropriate for this newsgroup, I apologize.
 I urge you to mail your answers. Thanks.)


I am about to do a survey or inventory of methods for software development.
With methods, I mean documented procedures and conceptual models for
either the entire development process or some parts thereof.

Anything worth being called a method in this sense is of interest.
Obviously, a complete inventory would be very large, but I hope
to be able to compile information about at least a large share of
the more widespread methods.

I wish to get as much information as possible about each method,
but the following will do fine:

                                                (for instance)

Name:                                           Coad/Yordon OOA and OOD
Key characteristics:                            Object oriented
Parts of development process concerned:         Analysis, design
Software tools supporting the method:           ...etc.
Result/output from method:
References:
- Documentation (title, author, etc):
- Organizations (commercial or other):


Please, if you have any references to a particular method, or if you
know of similar work elsewhere, mail me a reply. If there is enough
interest, I'll gladly post a summary. Your help is appreciated.

--
Ulf Lagerstedt, Communicator C3Consult, Sweden  /  ulf@c3consult.comm.se
Newsgroups: comp.object
From: dave@alex.uchicago.edu (Dave Griffith)
Subject: Re: Object hidden state and side effects
Organization: University of Chicago
Date: Sun, 20 Dec 1992 16:20:50 GMT

In article <knight.724800436@cunews> knight@mrco.carleton.ca (Alan Knight) writes:

>[Misattributes my stuff to Ben Bongalon, but I'll cope.]
>
>I can agree with most of this, but of course I have to add my two cents. 
>
>I agree entirely with Ralph Johnson that adding just the ability to
>distinguish values and objects is completely inadequate, and that a
>more comprehensive approach to describing code semantics is required.
>Given that you seem to be attempting to design a next-generation
>language, by all means explore this.

I'm on it.

>
>As far as the particular question of objects and values is concerned,
>there are really two separate issues which I think are orthogonal: the
>presence of an identity operation separate from equality and
>mutability. We get four classes of things, which I'm going to call by
>the names that have been used in this discussion, even if I don't
>think they're entirely appropriate.
>

The problem is just what your expecting equality to do.  If it's just
another comparison, then all of the following make sense.   If you also
expect equality to satisfy "substituting equals for equals gives equals",
things get more difficult.  In that case, mutable objects pretty much must
have equality as identity.

>Mutable objects: Have an identity operation, can be modified.
>The default case of objects.
>
>Immutable objects: Have no operations which modify state, but have an
>identity operation. e.g. non-mutable strings

Might be useful, although the need for an identity operation for non-mutable
strings escapes me.

>Values: Have no operations which modify state, have no identity
>operation. e.g. numbers
>
>Normal storage (or mutable values): State can be modified, but there
>is no identity operation. e.g. storage allocated on the stack in
>traditional languages. 

'Splain me, boss.  I'm feeling dumber than usual.

-- 
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       dave@alex.bsd.uchicago.edu
Become a sociopath.  We don't even have to sweat the big stuff.
Newsgroups: comp.object
From: harvey@opl.com (Harvey Reed)
Newsgroups: comp.object
Subject: Re: Object Request Broker
Date: 16 Dec 92 00:11:28 GMT

dvandrei@desperado.lerc.nasa.gov (Don Van Drei) writes:


>	Where can I find information on the Object Management Group(OMG)
>Object Request Broker?
>-- 

Write to Dr. Soley at:   soley@omg.org



-- 
++harvey
========================================================================
internet:  harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice:     617-965-0220
Newsgroups: comp.object
From: mat@mole-end.matawan.nj.us
Subject: Re: Object hidden state and side effects
Summary: The Big Lie, Memory Leaks, and GC
Organization: :
Date: Thu, 17 Dec 1992 09:24:30 GMT

In article <1992Dec17.001046.27321@crd.ge.com>, eaker@ukulele.crd.ge.com (Chuck Eaker) writes:

> |>          author = "A.N. Whitehead and B. Russell",
> |>          title = "Principia Mathematica",
 ...
> 
> I'd rather just summerize from memory: the symbol "2", for example,
> denotes the class of all couples. ...  But whatever theory ... you
> choose, it had better have as a consequence that the denoted thing is
> unique and can't be created or destroyed, etc. ...
 
> ... We populate our applications with "ordinary objects" which are things
> that come and go ...  Unfortunately, we are forced to use the same ordinary
> object construction mechanism to model domains of values. ...
 
> Very good object-oriented developers do understand all of this.  ...
> many of the really nasty problems ... have been the result of not being
> able to ... and cover up the "big lie": that an ordinary class mechanism
> is being used to implement a value domain ...  I suspect that
> the big lie may be behind most memory leaks.

And behind the need for GC.  GC is strong when objects represent values,
and when there is nothing that can say that the need for a given value
representation has ended.

BTW, the OO classes I've taught, and my forthcoming book on C++, suggest
categorizing candidate objects according to this scheme:

	Entity
		Thing (or person)
		Role
		Specification

	Relationship
		Association	(Instance-relates-to-instance)
		Agglomeration	(Anonymous collection)
		Organization	(Whole > sum-of-parts)

	Temporality
		Event
		Transaction
		Process

	Information
		Quantity
		Quality
		Selection

The last major category corresponds pretty well to value domains.
(That is, the book will have it if the publisher doesn't cut it;
the book is pretty well a tome!)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
From: johnson@cs.uiuc.edu (Ralph Johnson)
Newsgroups: comp.object
Subject: Re: Is Borland the leader in technology?
Date: 15 Dec 92 22:01:37 GMT
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

This thread really has less to do with OOP than it is a general
discussion of software engineering.

henley@eng.auburn.edu (James Paul Henley) writes:

>And do in a month what could be done in a few minutes?  NO THANKS!

and then:

>You are giving us a wonderful demonstration
>of the failure of a computer programmer to comprehend the problem that an
>engineer is trying to solve, and thinking that the solution is just a matter
>getting the engineer to do things YOUR way.  Well, this engineer knows better!

One thing that software engineers have a lot of experience with is being
thrown on projects and having to learn new fields and build systems that
are completely new to them.  We have learned that there is no substitute
to learning the problem domain, that if you don't know the problem domain
then you will end up working on the wrong problems to solve.  It takes a
lot of hard work and lots of communication to figure out the right problems
to solve and figure out how to build the right systems.  People who want
quick fixes are usually headed for trouble.

Now, none of us know the problems you are trying to solve.  I don't
understand what you want.  However, when I see you write that you expect
people to communicate primarily by tossing pieces of code back and forth, 
I expect you are not likely to be successful.

Why are you posting to this newsgroup?  What it is that you are looking
for?  This is not a crank comment; I'd like to know.

-Ralph Johnson
Newsgroups: comp.object
From: thinman@netcom.com (Technically Sweet)
Subject: Re: Object Relations - was: Re: Object hidden state and side effects
Organization: International Foundation for Internal Freedom
Date: Thu, 17 Dec 1992 18:42:18 GMT

CLOS, the Common Lisp Object System, uses "generic functions".
I'm sure other object systems do, also.  Under this paradigm,
an object or class is just a data structure with no embedded
methods.  "Generic functions" are separately defined operations
on the structure.  Generic functions can then be defined
that operate on two or more classes.  This is how inter-class
relationships are defined.  You don't say 'this is a vector'
'this is a matrix', 'gee, I have to put vector*matrix in
one of the two classes and then make them "friends" or make
one a subclass', you just define '*' as a generic function
on vectors and matrices.  

The problem is that you lose information-hiding because
you have to make vector and matrix open to the '*' function.


-- 

Lance Norskog

Data is not information is not knowledge is not wisdom.
Newsgroups: comp.object
Subject: Re: OOA&D Methodologies
From: j_ohearn@dsg4.dse.beckman.com ()
Date: 9 Dec 92 16:03:54 GMT
Distribution: world

In <ByxK7t.5v2@world.std.com> jwenn@world.std.com (John C Wenn) writes:

>rr@phavl.UUCP (rob) writes:
>an
>>In article <88289@bcsaic.boeing.com> Patrick Podenski writes:

>>"... had simply created yet another object-modeling methodology (YAO-MM)."

>>What are the well respected OOD, OOA, OOI methodologies?
>>I've found Booch's method, and OMT (Rumbaugh et al).
>>What else is worth looking at?


I have been monitoring and participating in the OO discussions on the net
for quite a while.  Based upon the mail I have received, the most popular
methodologies are (1) Object-Oriented Modeling and Design (Rumbaugh et al)
and (2) Object-Oriented Design with Applications (Booch).  It has been
my recommendation that the Rumbaugh techniques be used as the primary
methodology and that it be supplemented by the many pearls-of-wisdom that
can be found throughout Grady's book.  To be more specific, we do not
agree totally with Rumbaugh on every point, but we like his notation;
Booch helps shape our OO philosphy (sometimes to a greater extent than
Rumbaugh); furthermore, Grady has some concepts (like object timing
diagrams) that we find very useful (since we develop in a real-time,
multi-tasking environment).

Another topic I would like to bring up is CASE tools-- especially OO
CASE tools.  So far I am not very impressed but I would buy any CASE
tool that allows me to annotate any diagram artifact (this is critical
to capturing the HOW and WHY of your analysis and design so that you
do not forget and so others can step into your mind).

Thanks for listening.

Jim O'Hearn,
Software Engineer
Beckman Instruments Inc., Diagnostic Systems Group
Newsgroups: comp.object