HDTenEightyP/NetNews huggingface dataset:
From: cwalker@elnath.bucknell.edu (carleton walker `93)
Newsgroups: comp.object
Subject: Object-Oriented Prolog
Date: 5 Oct 1992 13:37:31 GMT
Organization: Bucknell University, Lewisburg, PA
NNTP-Posting-Host: elnath.cs.bucknell.edu


--
Carl Walker				"Hectic days ahead of us,
Bucknell University			 Rotten ones behind,
Lewisburg, PA				 Keeping plastics in our pockets,
cwalker@canopus.bucknell.edu (! tmc.edu) Children never mind." - K, S, & W
From: jb8285@guinea (Jeffrey R. Brown)
Newsgroups: comp.object
Subject: Re: OO Test Methods
Date: 5 Oct 92 20:22:35 GMT
Organization: Medtronic, Inc.

neil@ogicse.cse.ogi.edu (Neil Van Dyke) writes:
: Can anyone point me towards info on testing of OO systems?
: 
: Thanks,
: neil@cse.ogi.edu
: 

I would like to know, too.

--
Jeffrey R. Brown                Internet: jeffrey.brown@medtronic.com
Medtronic, Inc. (T430)          UUCP:     uunet!medtron!jb8285
7000 Central Avenue N.E.        Voice:    1-612-574-4698
Minneapolis, MN 55432 USA       FAX:      1-612-574-6150
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
From: richieb@bony1.bony.com (Richard Bielak)
Subject: Re: comparing object-oriented platforms
Organization: multi-cellular
Date: Wed, 30 Sep 92 20:46:50 GMT

In article <1992Sep29.235000.3583@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:

[...]

>  I happen to agree that Smalltalk is a higher risk language for
>  industrial applications. There is no static type checking. I do not want to
>  find out at run time that there are type errors in the system!
>  There are enough other types of errors to contend with, not to mention
>  budget and time constraints, without having to deal with highly confused
>  users confronted with a type error and some wierd system message
>  that terrifies them that they just lost a days work!
>

What about C or COBOL? I would say that the risk in using those is
greater in using than in using SmallTalk. Is "segmentation fault" a
friendlier message? :-)

[...]

>
>  Before this capability Smalltalk had some advantage over Eiffel in the speed
>  of the turn around from change to testing. 

One thing that I like in Smalltalk that is not present in Eiffel is
the ability to treat code (i.e. blocks) as objects. 

[...]

>
>   Eiffel does not deny the right of the older style to exist.
>   It simply treats it as a separate world. This is much cleaner
>   and easier to comprehend, learn and manage. Eiffel can call external
>   C/C++ modules. Also Eiffel objects can be called from C and I guess
>   from C++. So we have a neat path for evolution into a new paradigm
>   The old C/C++ code can be reused as long as it is useful by encapsulating 
>   it with Eiffel classes. 

Well, I'm not so sure it's that easy to call C++ from Eiffel. First of
all you'd need to find out all those mangled names of C++ routines,
never mind the setup that the C++ compiler does before invoking the
main. This is not just a problem with Eiffel, you'd have the same
problem if you were using C.

I guess a solution would be to use a C++ compiler on the output of
Eiffel compiler.


The other directions work fine (i.e. call Eiffel from C++ or C).


...richie



-- 
* Richie Bielak   (212)-815-3072   |                                          *
* Internet:       richieb@bony.com | Rule #1: Don't sweat the small stuff.    *
* Bang {uupsi,uunet}!bony1!richieb | Rule #2: It's all small stuff.           *
*    - Strictly my opinions -      |                                          *
Xref: sparky comp.object:3824 comp.lang.smalltalk:2009 comp.lang.eiffel:1221
From: nedervol@schaefer.math.wisc.edu (Eric Nedervold)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: comparing object-oriented platforms
Date: 2 Oct 92 18:04:54 GMT
Organization: Univ. of Wisconsin Dept. of Mathematics

richieb@bony1.bony.com (Richard Bielak) writes:

>In article <1992Sep29.235000.3583@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz 
 writes:

>One thing that I like in Smalltalk that is not present in Eiffel is
>the ability to treat code (i.e. blocks) as objects. 

I'm only an Eiffel and Smalltalk fan, never having gotten my hands on a
system for either, but it seems that there are a number of situations where
a CodeObject would be useful in Eiffel (simulating procedure-valued variables
in Modula-2, etc.).  It seems easy to construct: a virtual class with a
single feature Do.  This defines the abstract class and to instantiate it,
you build subclasses.  It *is* grungier than just putting brackets around
the code like Smalltalk, but it seems equally functional.

Is it just the grunginess that is the problem, or does my lack of Smalltalk
experience cause me to miss a more subtle issue? 

--Eric
Newsgroups: comp.object
From: dsr@bnr.co.uk
Newsgroups: comp.object,comp.software-eng
Subject: Domain analysis
Date: 30 Sep 92 17:00:50 GMT
Reply-To: dsr@bnr.co.uk ()
Organization: BNR Europe Limited, London Road, Harlow, Essex, GB

Hi,

I'm looking for some good books on Domain Analysis and would
appreciate any pointers please.


   Dave Riches
   Email:  David.S.Riches@bnr.co.uk
   Smail:  BNR Europe Ltd, London Road,
           Harlow, Essex. CM17 9NA.  England
   Phone:  +44 (0)279-402496
   Fax:    +44 (0)279-451434
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Passing functions as parameters in an OO environment
Organization: University of Jyvaskyla, Finland
Date: Tue, 29 Sep 1992 09:09:23 GMT

In article <knight.717521079@cunews> knight@mrco.carleton.ca (Alan Knight) writes:
>In <1992Sep23.080013.19249@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>
>>In article <m77nzwn.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
>>>C++ has function pointers and pointers to members for member functions
>>>(methods).  Nothing that doesn't fit in here...
>
>>But C++ is a highly hybrid language.  It also has things like
>>pointer arithmetic, which is extremely contrary to object orientation.
>>In more purely OO languages, procedures typically cannot be used as
>> ...
>Which purely object-oriented languages are you referring to? While
>Smalltalk doesn't let you pass methods as such, you can pass either
>blocks or method names, both of which achieve the desired effect. I
>would be extremely surprised if CLOS didn't let you pass functions
>around, being derived from LISP. I don't know about Eiffel or Simula,
>but my opinion of them would go down considerably if I found out they
>couldn't do this.  I'd consider it a requirement for a decent
>programming language.

All right, since Smalltalk is the best-known purely OO language,
'typically' was perhaps out of place! (*)
CLOS obviously is a hybrid language if any, and so is Simula
(which does allow procedures as parameters, like Algol 60 on which
it was based).  Eiffel certainly does not allow it;  I don't remember
about Trellis/Owl (tm), DEC's strongly typed, purely OO language.
The other DEC language, Modula-3, allows procedures as parameters,
but its main goal was not object orientation in the first place.

(*) However, I don't count passing a method _name_ as at all equivalent
to passing a procedure, because method binding is always fully dynamic
in Smalltalk.  Even the "pointers to member functions" in C++ are not
exactly equivalent to procedure values (or pointers) if the member function
(method) pointed to is virtual.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Xref: sparky comp.object:3839 comp.lang.smalltalk:2029
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.object,comp.lang.smalltalk
Subject: Re: comparing object-oriented platforms
Date: 4 Oct 92 22:23:05 GMT
Reply-To: tmb@idiap.ch
Followup-To: comp.object
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: burchard@horizon.math.utah.edu's message of 4 Oct 92 00:34:33 GMT

In article <1992Oct4.003433.22712@news2.cis.umn.edu> burchard@horizon.math.utah.edu (Paul Burchard) writes:

   In article <TMB.92Oct3215246@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M.  
   Breuel) writes:
   > In article <ken8Xe_00awRQ5OHYd@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
   > >Static type checking makes it harder to develop code in limited
   > >time (prototype doesn't have to be bug free, nor fast, nor complete)
   > 
   > In my experience, static type checking _in a polymorphic type system
   > with type inference_ makes it easier and faster to get code working;
   > it doesn't make it harder. As an added bonus, it does help reduce the
   > frequency of bugs, and  
   it does help make your code run faster.
   > 
   > If you don't have a polymorphic type system with type inference, then
   > I agree that static type checking is a bother.

   That is still too rigid.  What you really want is
   "just-the-right-amount" of type checking that will exactly
   communicate your desired design constraints to the compiler, while
   avoiding that odious type-checking rigor mortis. [goes on to
   talk about Objective-C]

I think we may have different notions of "polymorphic" here. I'm
talking about Milner-style polymorphism (as found in SML and a few
other languages), not OO-style polymorphism.

OO-style polymorphism is more restrictive than Milner-style
polymorphism, and also too restrictive for my tastes in the presence
of a static type checker.

So, please be clear. _What_ "is still too rigid"?

					Thomas.
Xref: sparky comp.object:3753 comp.lang.smalltalk:1943 comp.lang.eiffel:1176
From: eberard@bse.com (Edward V. Berard)
Newsgroups: comp.object,comp.software-eng
Subject: New Book: Essays on Object-Oriented Software Engineering, Volume 1
Summary: availability and contents of new book on OOSE
Keywords: object-oriented software engineering
Date: 5 Oct 92 22:43:36 GMT
Reply-To: eberard@bse.com (Edward V. Berard)
Organization: Berard Software Engineering, Inc.
X-Mailer: uAccess - Macintosh Release: 1.6v1

I would like to announce the availability of my new book: "Essays on
Object-Oriented Software Engineering, Volume 1." The book is hard
cover, and is approximately 360 pages. The publisher is Prentice Hall
and the ISBN Number is 0-13-288895-5.

(The "in stock date," i.e., the date it will be in Prentice Hall's
warehouses, is the week of October 12-16, 1992. Prentice Hall has told
me that copies will be available at this year's OOPSLA.)

The table of contents reads as follows:

 Preface
 Chapter 1	Understanding Object-Oriented Technology
 Chapter 2	Motivation for An Object-Oriented Approach to Software Engineering
 Chapter 3	What Are Methodologies?
 Chapter 4	Life-Cycle Approaches
 Chapter 5	Understanding the Recursive/Parallel Life-Cycle
 Chapter 6	Abstraction, Encapsulation, and Information Hiding
 Chapter 7	Object Coupling and Object Cohesion
 Chapter 8	Object and Class Specifications
 Chapter 9	Large Object-Oriented Entities (Systems of Objects)
 Chapter 10	Object-Oriented Domain Analysis
 Chapter 11	The Creation of and Conversion to Object-Oriented Requirements
 Chapter 12	Object-Oriented Requirements Analysis
 Chapter 13	Object-Oriented Design
 Chapter 14	Evaluating an Object-Oriented Programming Language
 Chapter 15	Issues in Testing Object-Oriented Software
 Chapter 16	Specifying Test Cases for Object-Oriented Software
 Chapter 17	Readings in Object-Oriented Technology
 Appendix	[9 sample Object and Class Specifications]
 Glossary
 Index

Thanks for any interest.

				-- Ed

----------------------------------------------------------------------------
Edward V. Berard                                | Phone: (301) 417-9884
Berard Software Engineering, Inc.               | FAX:   (301) 417-0021
101 Lake Forest Blvd., Suite 360                | E-Mail: eberard@bse.com
Gaithersburg, Maryland 20877                    | 
----------------------------------------------------------------------------
From: bub@qut.edu.au
Newsgroups: comp.object
Subject: perspective in objects
Date: 27 Sep 92 16:54:39 EST
Organization: Queensland University of Technology

X-NEWS: wattle comp.databases: 13935
From: bub@qut.edu.au
Newsgroups: comp.databases
Subject: perspective in objects
Date: 25 Sep 92 17:04:35 EST
Organization: Queensland University of Technology

People talk about object-oriented a long time. Most of them said, the objects
are just the real world.  But the world is not just the thing you can see and
you can touch.  Some thing half in physical and half in mind.  Somethings are
totally in mind.  Even some experts have not idea how to model these kind 
objects.

Have you met the things that seem different from different situations and for
different purpose.  But actually they are the same in "data". Does we need some
physical->mind->show convertion models or other kind of model to describe
perspective insight? If we need, what is its fundamentalform?

Welcome discussing and giving some information to me. If you have any idea, 
talk in this newsgroup or e-mail to 

w.li@qut.edu.qut

I like to write a report about this, I hope I can mention your name in my
reports.

Newsgroups: comp.object
From: sjbr@cs.utwente.nl (Sjaak Brinkkemper)
Subject: Re: Looking for OO Methodology Comparisons
Summary: Two new references for OO method comparisons
Keywords: OO methods, comparison, methodology
Organization: University of Twente, Dept. of Computer Science
Date: Wed, 30 Sep 1992 15:17:40 GMT


In article <2926342200.2.p00058@psilink.com> "Ronald C. Schultz" <p00058@psilink.com> writes:
>Numerous object-oriented methodology comparisons currently 
>exist in the literature. 
>
> <Text deleted>
>
>I am interested in any other comparisons that you may know of, as well as 
>their prices and how they can be obtained.  Thanx.
>

Here are two extra:
[van den Goor et.al., 1992] G. van den Goor, S. Hong and S. Brinkkemper, 
A Comparison of Six Object-oriented Analysis and Design Methods. Report
method Engineering Institute, University of Twente, the Netherlands, and 
Computer Information Systems Department, Georgia State University, Atlanta
USA, 1992, 163 pages.

This report compares the background ideas, steps, concepts, notations, 
communication mechanism, and the specification techniques of six accepted 
methods, that are available in textbooks. The comparison is performed by
meta-modelling, yielding detailed information on concepts (in EER notation)
and steps (in task diagrams).  Extensive comparison tables of steps, 
concepts, techniques are included, as well as mappings of the methodical
concepts to the constructs of programming languages (Smalltalk, C++, 
Eiffel, a.o.) Six methods are: Booch, Martin/Odell, Coad/Yourdon, Rumbaugh,
Wirfs-Brock, Shlaer/Mellor.
Available for North America through OSoft Development Corp. 
Call 404-875-2216 for pricing and availability. Elsewhere call +31.53.893690
(Netherlands) or mail to sjbr@cs.utwente.nl.

[Hong et.al. 1992] S. Hong, G. van den Goor and S. Brinkkemper, 
A Comparison of Object-oriented Analysis and Design Methods. Working paper, 
Computer Information Systems Department, Georgia State University, Atlanta
USA, 1992, 12 pages. To appear in the Proceedings of the 26th Hawaiian 
international conference on System Sciences, IEEE Computer Science Press.

This paper is a summary of the report [van den Goor et.al., 1992].
Discusses the comparison approach and gives excerpts of the comparison results.
Available from the authors at cisssh@gsu2.gsu.edu or sjbr@cs.utwente.nl.


Sjaak Brinkkemper, Design Methodology Group
Department of Computer Science, University of Twente, 
P.O. Box 217, 7500 AE Enschede, the Netherlands
tel +31.53.89.3690; fax +31.53.33.9605; sjbr@cs.utwente.nl

Newsgroups: comp.object
From: acmtsv@gsusgi2.gsu.edu (Thomas Scott Vaughn)
Subject: Finding good applcations for OOPL
Organization: Georgia State University
Date: Wed, 30 Sep 1992 23:48:51 GMT


I'm doing research on the use of OOPL by the private sector.  I'm
looking for some common benefits and problems that software developers
have experienced using OOPL, in order to gain a better understanding
of what OOP is good for.  I'm especially interested to hear about 
the specific failures you've had using OOP.  Was it too complex?  Too
cumbersome?  Please take a minute to fill out the following
questionaire and mail it to me.  Feel free to be as verbose or as
brief as you like.  Any responce will be appreciated.

Thanks.
Tom Vaughn
acmtsv@gsusgi2.gsu.edu

----------------------------------------------------------------------
Name (optional):


Company and location (optional):


Applications and OOPL used:


Benefits gained from using OOP:


Problems incurred from using OOP:


Xref: sparky comp.object:3760 comp.lang.smalltalk:1954 comp.lang.eiffel:1184
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: comparing object-oriented platforms
Date: 29 Sep 92 14:18:16 GMT
	<1992Sep28.024059.25761@actrix.gen.nz>
Reply-To: tmb@idiap.ch
Followup-To: comp.object, comp.lang.smalltalk,comp.lang.eiffel
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: Des.Kenny@bbs.actrix.gen.nz's message of 28 Sep 92 02:40:59 GMT

In article <1992Sep28.024059.25761@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:

                           But C++ is a poor compromise at best.
			   It is not real OO.

I'm really glad that C++ is a compromise between OO and non-OO
facilities. If it weren't, it would be much less expressive and much
less useful.

			   Look at the various platforms and judge for yourself.
			   Decide what you need that suits you. Don't go on the
			   number of licenses!

I did; Eiffel didn't suit me.

					Thomas.
Newsgroups: comp.object,comp.lang.objective-c,comp.lang.c++
From: paul@allink.com (paul reiber)
Subject: LOOKING FOR: a good unix DOMF...
Organization: NYNEX ALLINK Company
Date: Tue, 29 Sep 1992 23:12:48 GMT

Hello, world.

 ** I need to find a clean, working, stable, fast, etc. DOMF. **

A Distributed Object Management Facility.  Though, I truthfully
don't care what you call it as long as it:

	- has a C, C++ or Objective-C API...

	- is fully (multi-machine) distributed...

	- provides some means of permanence, hopefully allowing
	  for an SQL-based db interface to (Ingres, Sybase, whatever)

	- can handle a humongous amount of relatively static data
	  living right next to some fast-moving dynamic data...

	- lets me define a model of what's what and populate instances
	  from the above massive database on-the-fly...

	- (hopefully) handles internally some sort of usage algorithms
	  to manage what's `kept local' vs. `on demand'...

	- (hopefully) allows me to specify hints for a `preload' at
	  process startup...

	- (hopefully) allows for run-time mgmt. of properties/attributes
	  against the objects. (i.e. I can add and del, not just change)

Whether it's a product or PD isn't a concern as long as I can
use it inside something I'm selling... and, yeah, we can talk.

	Please email me:     paul@allink.com 
	Or call if you wish: (914)644-7729

All responses welcome: pointers, products, experiences, flames, etc.
(hrm... take back that flames part...)   :-)

Thank You!
-- 
 +---------------------+------------------------+-----------------------------+
 | Paul B. Reiber, Jr. | NYNEX Allink Company   | "To Invent, you need a good |
 |  (914)  644 - 7729  | 4 Gannett Drive,       |  Imagination and a Pile of  |
 |   paul@allink.com   | White Plains, NY 10604 |  Junk."     - Thomas Edison |
Newsgroups: comp.object
From: rlglende@netcom.com (Robert Lewis Glendenning)
Subject: Re: Eiffel for Macintosh
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 2 Oct 1992 16:23:38 GMT

I wanted to second the request for Eiffel for the Mac. In my experience
(wide), MPW is a very productive environment.

Eiffel in MPW would be a dream. There are certainly enough MacApp people
interested in Eiffel to produce the interfaces.

Lew
-- 
Lew Glendenning		rlglende@netcom.com
"Perspective is worth 80 IQ points."	Nils Bohr (or somebody like that).
Newsgroups: comp.object,comp.lang.objective-c,comp.lang.c++
From: bhonsle@sf49ers.iss.nus.sg (Shailendra K Bhonsle)
Subject: Re: LOOKING FOR: a good unix DOMF...
Organization: Institute of Systems Science, NUS, Singapore
Date: Tue, 6 Oct 1992 05:34:06 GMT

Hi,
Can you summarize the info that you got? I will appreciate it very much 
if you post it to the net as well.

Thanks

Shailendra

--
From: ssmith@LOX.intel.com
Newsgroups: comp.object
Subject: o.m(...) vs m(...), and is the real world o-o?
Date: 6 Oct 92 23:49:02 GMT
Reply-To: <ssmith@LOX.intel.com> (Stephen P. Smith)
Organization: Az-Kal

In article<1992Oct4.150650.9408@ucc.su.OZ.AU>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> 
> SO all systems either enforce the interface or they crash,
> either at compile time or run-time or both. At compile time
> is far better, for obvious reasons.
> 

Funny, my machine doesn't crash when it gets run-time errors:

(defun add-to-nil (x) (+ x nil))
ADD-TO-NIL
(compile 'add-to-nil)
ADD-TO-NIL
(add-to-nil 10)
Trap: The second argument to the ADD instruction, NIL, was not a number
While in the function ADD-TO-NIL  SI:*EVAL  EVAL

ADD-TO-NIL
   Arg 0 (X): 10
s-A,    Supply replacement argument
s-B:    Return a value from the ADD instruction
s-C:    Retry the ADD instruction
s-D,    Return to Lisp Top Level in Dynamic Lisp Listener 2
s-E:    Restart process Dynamic Lisp Listener 2
 Return a value from the ADD instruction
Form to evaluate and return: 100
100

I can tell the machine to do the right thing(tm).

Perhaps you are using old software? :-)

--Steve
Newsgroups: comp.object
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Why is garbage collecting considered intregral to OOPS?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 27 Sep 1992 15:50:06 GMT

In article <fb#pgkl.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
>In article <4289@seti.UUCP> Daniel R. Edelson <edelson@sor.inria.fr> writes:
>>The problem with all this stuff is that smart pointers don't
>>work like regular pointers. They have different overloaded
>>function resolution and they don't support the same standard
>>conversions. They're very difficult to retrofit into existing
>>code. They cannot be members of unions (due to having a 
>>constructor). 
>
>I can see the union problem but I don't see the rest because counted
>pointers just use the overloaded arrow operator to forward messages
>to the inner class.  

	Overloaded function resolution:

	f(A*);

	This function wont accept a smart pointer class Handle<A>.

	Conversions.

	class Base {}
	class Derived : public Base {}

	Derived *d=new Derived();
	f(Base*);
	f(d); // OK, converts automatically

	f(Handle<Base>);
	Handle<Derived> d;
	f(d); // error, wont convert

Real pointers have a special property that smart one dont.
When I derive Derived from Base, there is a sort of
automatic derivation of Derived* from Base*, and this
is what makes polymorphism work in C++.

A genuine 'smart pointer' must have this property,
that is, Handle<Derived> really must derive from
Handle<Base> as well as being generated by
the template Handle. But it doesnt.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.object,comp.lang.c++