HDTenEightyP/NetNews huggingface dataset:
From: martinher@urvax.urich.edu (Herb Martin - martinher@urvax.urich.edu)
Subject: Re: C++ Component Toolkit Evaluation
Reply-To: martinher@urvax.urich.edu
Organization: University of Richmond
Date: Sun, 11 Oct 1992 07:14:19 GMT

>I am evaluating C++ component toolkits.  I am looking at Tools.h from Rogue Wave
>and the Booch Componenets.  Does anybody have real world / applications exp-
>erience with either of these products.  How was your experience?  Would you 
>recommend the software for a commercial product?
>
>Are there other toolkits / component libraries for C++ that I should also be 
>investigating?
>
We intend to standardize on MPW C++ with MacApp for the Macintosh and 
Borland C++ using their Object Windows Libraries.  I am very interested
in your results.

I wonder what additional libraries I should automatically offer to my 
developers? 

**************************************************************
**   Herb Martin               MartinHer@urvax.urich.edu    **
**   JRC-41-1, P.O. Box 26603, Richmond, VA 23261           **
**   804-274-4325 (days)       804-320-5047 (evenings EST)  **
**************************************************************


**************************************************************
**   Herb Martin               MartinHer@urvax.urich.edu    **
**   JRC-41-1, P.O. Box 26603, Richmond, VA 23261           **
**   804-274-4325 (days)       804-320-5047 (evenings EST)  **
**************************************************************
Newsgroups: comp.object
From: brianm@ecst.csuchico.edu (Brian Meyerpeter)
Newsgroups: comp.object
Subject: Any interest in a Seminar on the Common Object Request Broker?
Date: 8 Oct 92 00:31:21 GMT
Organization: California State University, Chico
NNTP-Posting-Host: cscihp.ecst.csuchico.edu


I'm thinking of putting a 1 day course together outlining what CORBA is
and what it may mean to software end-user and development people.

Do you think there would be much of a demand for it?

Thx
Brian
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Window as a subclass of Rectangle?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sat, 10 Oct 1992 22:36:49 GMT

I find that people often use inheritance to model the relationship
between two classes when they really should make an instance of one
class be a component or an attribute of another.  My favorite example
is one that I have seen in several papers: Window is made a subclass
of Rectangle.  It seems much better to say that every Window has a
shape, and the shape might be (or may always be) a Rectangle.

I'm writing a paper in which I want to reference one of these papers.
Wouldn't you know it, I can't remember where I saw them.  Can anybody
give me a point to a paper that makes this mistake?  It will probably
be an early paper, since people don't make this mistake in public as 
much any more.

Ralph Johnson -- johnson@cs.uiuc.edu
From: ogden@seal.cis.ohio-state.edu (William F Ogden)
Newsgroups: comp.object
Subject: Re: Basis of OOP
Keywords: OOP,Mathematics
Date: 13 Oct 92 21:08:01 GMT
Article-I.D.: cis.1992Oct13.210801.20457
Organization: The Ohio State University Dept. of Computer and Info. Science

In article <Bvvstz.FJv@world.std.com> rjk@world.std.com (robert j kolker) writes:
   ...
>The proper underlying mathematical model for relational databases is
>either Relational Algebra with limited complementation or a restricted
>first order logic for n-adic predicates.

>The proper underlying mathematical model for LISP is lamba-calculus.

>The proper underlying mathematical model for Prologic is first order logic
>restricted to Horn Clauses.

>Question: What is a proper underlying mathematical model for OOP?

Unfortunately, no single simple mathematical model will do. In essence,
the objects in OOP can, in principle, come from any mathematical domain,
so an adequate mathematical basis needs to include all of mathematics --
including the higher order parts. (Perhaps this is not so surprising,
since the aim of mathematics is to develop suitable models for all the
various domains of world knowledge and our aim is to provide a way to
compute with objects in all these same domains.)

This is why various developments such as Z, VDM, etc. are being undertaken
to try to provide an industrial strength version of mathematics which is
suitable for use in specifying the full spectrum of entities that will
arise in OOP.

-- 

/Bill
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
From: wicklund@intellistor.com (Tom Wicklund)
Subject: Re: Documenting programs written in OOLs
Organization: Intellistor, Inc.
Date: Fri, 16 Oct 92 20:12:07 GMT

In <1992Oct15.032937.1909@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes:

>mwu@orion.oac.uci.edu (Matt Wu) writes:

>>Is there a particularly good way to document classes/application code
>>that works especially well with object-oriented languages?

>Yes, if the language is consistent, simple, and lends itself to a
>neat style, it is the program itself. Further down in your post,
>you say you want something separate from the program. If you think
>about this away from the current debacles of languages like C++,
>then one document can be used to capture all the relevant information
>about a project. Viewing a program as a document has quite a
>number of benefits. Firstly, a language is formal, and can therefore
>be processed in many ways, in addition to straight compilation.
>Secondly, changes made to the program, are implicitly in the
>documentation. This saves cost and effort in updating separate
>documentation, but also saves as mistakes will not be made. Anyway,
>I shan't write a treatise on the benefits here, but leave you to
>think about them.

While this is nice in theory, too often the formal language isn't as
obvious as English text.  As a simple case, it's easier to read:

  "X must be even"

Than to to read something like:

  "invariant X mod 2 = 0"

This becomes more and more true with more complex examples.  For
instance, take UNIX style regular expressions.  Can one document how
to write a regular expression using the code in a form which is easy
to read?  I assume that the original poster is looking for a way to
document classes for users of the class rather than the class
maintainer.

Formal specifications can be a very useful part of a program, for
example in Eiffel or Anna.  They define more precisely the
relationships between values and rules to be followed when using code.
They are also useful in ensuring that changes to code still follows
the basic rules for that code.  However, I'm not sure they can replace
text documentation.
From: trathenac@brt.deakin.edu.au
Newsgroups: comp.object
Subject: Case studies wanted
Date: 5 Oct 92 20:17:26 GMT
Organization: Deakin University, Melbourne


I am looking for case studies of small systems that have used the
Object-Oriented approach for analysis, design, and coding.
The case studies will be used as teaching materials for third year
software engineering students.

The Coad/Yourdon methodology is preferred.

Thanks in advance,

----------------------------------------------------------------------
Chris Trathen
Technology Management Centre   _--_/\  
Burwood Campus                /      \     trathenac@brt.deakin.edu.au
Deakin University             \_.--._/          Fax: +61 3 888 8562
Australia                           v         Phone: +61 3 805 3936
----------------------------------------------------------------------
Newsgroups: comp.object
From: pphilp@vizbiz.com
Subject: C++ Component Toolkit Evaluation
Organization: Visible Decisions Inc
Date: Tue, 6 Oct 1992 16:59:29 GMT

I am evaluating C++ component toolkits.  I am looking at Tools.h from Rogue Wave
and the Booch Componenets.  Does anybody have real world / applications exp-
erience with either of these products.  How was your experience?  Would you 
recommend the software for a commercial product?

Are there other toolkits / component libraries for C++ that I should also be 
investigating?

Thank you for your help,
Paul


Paul Philp
Visible Decisions      65 Front St. West,         
Suite 110-140                                     _____
Toronto, Ontario,      CANADA  M5J 1E6           |     | 
pphilp@vizbiz.com                                |  *  |          
vox: (416) 864-4342    fax: (416) 864-3918       |_____|      
Newsgroups: comp.object
From: night@acm.rpi.edu (Trip Martin)
Subject: Re: alternatives to "strict OO"? (Re: comparing object-oriented platforms)
Reply-To: night@acm.rpi.edu
Distribution: na
Date: Wed, 14 Oct 1992 01:03:06 GMT

In <TMB.92Oct12221117@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

>monomorphic statically typed languages _if_ you have closures. So,

If you don't mind my asking, what is a closure?
-- 
Trip Martin
night@acm.rpi.edu
--
Trip Martin
night@acm.rpi.edu
Newsgroups: comp.object
From: dlw@atherton.com (Remo Williams)
Subject: Re: LOOKING FOR: a good unix DOMF...
Organization: Atherton Technology, Inc.
Date: Mon, 12 Oct 1992 21:09:17 GMT

In article <1992Sep29.231248.7115@allink.com> paul@allink.com (paul reiber)  
writes:
> Hello, world.
> 
>  ** I need to find a clean, working, stable, fast, etc. DOMF. **
> 	- has a C, C++ or Objective-C API...

NeXTSTEP 3.0 has this--it is called Distributed Objects.
> 
> 	- is fully (multi-machine) distributed...

Distributed objects can be stored anywhere a NeXTSTEP platform can access it.

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

NeXTSTEP 3.0 with DBkit (bundled) allows this.

--
David Williams -- dlw@atherton.com -- NeXTMail welcome
	          dlw@netcom.com   -- NeXTMail welcome 
					
Newsgroups: comp.object
From: oscar@cui.unige.ch (Oscar Nierstrasz)
Subject: Re: OO Concurrency Control (Was: OO Concurrency)
Reply-To: oscar@cui.unige.ch
Organization: University of Geneva
Date: Thu, 15 Oct 1992 09:24:19 GMT

In article 239@dsg.cs.tcd.ie, cjmchale@dsg.cs.tcd.ie (Ciaran McHale) writes:
>At the ECOOP '92 workshop on OO concurrency there was some discussion of
>this. Several people seemed to agree that:
>
>	/1/ One task of synchronisation is to ensure the data
>	    consistency of the object. Since it is often possible to
>	    implement an object type in several different ways (e.g., a
>	    buffer might use an array or a linked list) the
>	    synchronisation is an implementation issue and should *not*
>	    be visible in the object's type specification.
>
>	/2/ The synchronisation on an object could affect the workings
>	    of its clients (an example is given above). Therefore an
>	    object's sychronisation *should* be visible in its type
>	    specification.
>
>The observant reader will notice that /1/ and /2/ contradict each other.
>:-)
>
>Research needs to be done to solve this paradox.

Actually, it's not such a paradox -- what needs to be stated clearly is
the client/server contract that the object conforms to.  This may include
some liveness and safety properties wrt synchronization.  Beyond that,
the implementor should have complete freedom to choose any synchronization
strategy that satisfies the contract.  If the "contract" is nothing more
than a set of operations, that suggests that all requests will eventually be
serviced.  In the case of a "container" object, the contract should state
that the number of gets must be no more than the number of puts.  Then
stacks and queues and other of your favourite containers (concurrent or
sequential) may choose any synchronization scheme as long as the contract is
satisfied.  A container that blocks "puts" when it becomes full would
not satisfy the contract, so the contract would have to be weakened in
such a case.

Ideally, contracts should be part of the type system and should be type-checkable.
This implies, in turn, that you shouldn't try to specify too much, or you will
be unable to verify the contracts statically.  (It is not clear where the
boundary lies between checking of type safety and program verification -- in
concurrent systems, type checking should include some limited dynamic analysis,
it seems, to deal with these issues.)

So far no one has the solution, so ... even though there is not really any
paradox, there is still research to be done.

Oscar


-------------------------------------------------------------------------------
	Dr. O.M. Nierstrasz, Centre Universitaire d'Informatique
University of Geneva, 24, rue du General-Dufour, CH-1211 Geneva 4, Switzerland
Tel: +41 22 705.7664  Fax: 320.2927 Home: 733.9568  E-mail: oscar@cui.unige.ch
-------------------------------------------------------------------------------
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.object
Subject: Re: OOP not GUT of programming?
Date: 12 Oct 92 02:29:15 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: objsys@netcom.com's message of 11 Oct 92 00:30:41 GMT

In article <1992Oct11.003041.20992@netcom.com> objsys@netcom.com (Bob Hathaway) writes:

   And since OO advocates encapsulation and reuse (and etc.), it is a superior
   methodology to whatever else is out there.

Several programming technologies besides OOP advocate encapsulation
and reuse. OOP certainly is better than some methodologies out there,
but it is not clearly better than all other methodologies.

					Thomas.
Xref: sparky comp.object:3956 comp.lang.smalltalk:2130 comp.lang.eiffel:1258
From: diamond@jit533.jit.dec.com (Norman Diamond)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: OO Concurrency
Date: 15 Oct 92 08:39:22 GMT
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo

In article <1992Oct13.125227.22956@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:
>Is a thread-of-control an object?

I vote yes.  And even more strongly, I would assert that a continuation
is an object.  A server or a "manager" (delegator) should be able to
hand off a continuation to another server, for eventual resumption when
its request has been served.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
Newsgroups: comp.object
From: coyote@cc.gatech.edu (Stephen C. Arnold)
Subject: Re: Object-Oriented Prolog
Reply-To: coyote@cc.gatech.edu (Stephen C. Arnold)
Organization: College of Computing, Georgia Institute of Technology
Date: Fri, 16 Oct 1992 13:49:06 GMT

Georgia Tech Research Institute (the ATESSE project) created its own
object-oriented prolog for a circuit analysis project.  I did some work
on this system ([G]eorgia Tech [O]bject-[O]riented Pro[LOG], GOOLOG for
short).  We used this system with serval 100 to 1000 objects.  If people
are interested, I may be able to dig up some for information about the
results.

Overall, the system worked well, but slowly,  We implemented it in
Quintus Prolog on HP (formerly, Apollo workstations).

Stephen Arnold (coyote@cc.gatech.edu)

Newsgroups: comp.object
From: lse@dxcern.cern.ch (Lionel Sacks)
Subject: Re: OOP not GUT of programming?
Organization: CERN European Laboratory for Particle Physics
Date: Thu, 8 Oct 1992 10:55:31 GMT

>In article <5OCT199215551226@elroy.uh.edu> st1lv@elroy.uh.edu (McLeod, Stephen) writes:
>I have been talking to a lot of people about this lately and some had the view
>that OOP was basically a good algorithm for handling the data base handling
>aspect of a solution be it an OS, a Database, or a guided missile program but
>that it was not appropriate for writing, say, a compiler, a text editor and
                                                 ========
>so on.

If you look into the guts [sic] of gcc you will find that many 'methods'
which are target/host spacific are 'virtual'. I suppose because they 
cannot depend on having g++ on the host, this is done with cpp macros. 
If your target/host needs to 'override' a method, you #undef the default
macro & #def your own. 
 So far as OOP isn't a language, but a method, certainly gcc is built OOly.
(any FSF people out there; did you do it on purpos?).
Newsgroups: comp.object
From: jessel@irit.irit.fr (Jean-Pierre JESSEL)
Newsgroups: comp.object
Subject: OO engineering in SF, Ca, in July 1992
Keywords: object-oriented langage, software engineering
Date: 16 Oct 92 11:27:27 GMT
Organization: IRIT-UPS, Toulouse, France

Hello Net Users,

I post this message for a friend who has no access to this newsgroup.

His query is :

What do you know about a conference, or a workshop, or an exhibition, in San
Francisco, in July 1992, which purpose was object-oriented technologies, oo
development tools, oo environments ?

Please answer directly to me : jessel@irit.fr

Thank you for your help.
Organization: The American University - University Computing Center
Date: Fri, 9 Oct 1992 18:39:03 EDT
From: bj gleason <BJGLEAS@auvm.american.edu>
Newsgroups: comp.object
Subject: Seeking Roman Zielinski - Author of OOT

Does anybody have the email address for Roman Zielinski?

He is the author of OOT for windows, an excellent package.

Many thanks...

bj
Newsgroups: comp.lang.eiffel
From: keck@castor.trl.OZ.AU (Brian Keck)
Subject: Re: Request for info - Software Testing Tools
Organization: Telecom Research Labs,Melbourne, Australia
Date: Fri, 9 Oct 1992 14:54:25 GMT



In comp.software-eng, scip2060@nusunix1.nus.sg (SARDJONO INSANI) asked:
	REQUEST FOR INFO - SOFTWARE TESTING TOOLS
	Could anyone please give me information on software testing tools
	commercially available, with brief comments of their functionality,
	price and address of vendors?

I have what I guess is a similar question.

What I have in mind are tools that take up where lint leaves off,
for C primarily, but also C++ & Eiffel.

I've seen the thread on Purify/dbmalloc/Sentinel, but am more interested
in programming style as it affects maintainability & other good things
(reliability, efficiency, portability, interoperability, ...).

Thanks for any help,

Brian Keck

b.keck@trl.oz.au, phone +61 3 253 6407, fax +61 3 253 6362 
Network Services & Signalling, Telecom Research Laboratories
770 Blackburn Rd, Clayton Victoria 3168, Australia
From: diamond@jit533.jit.dec.com (Norman Diamond)
Newsgroups: comp.lang.eiffel
Subject: Re: like current
Date: 9 Oct 92 05:57:33 GMT
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo

In article <A2083@WUe.maus.de> Markus_Klingspor@wue.maus.de (Markus Klingspor) writes:
>class tA
>feature
>        tst(t: tA): like current is do
>            result := t;

That assignment looks type-unsafe to me.  Does the language definition
really allow it?  I'd believe this if you coded it:
             result ?= t;
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
From: ian@syacus.acus.oz.au (Ian Joyner)
Newsgroups: comp.lang.eiffel
Subject: Re: Request for info - Software Testing Tools
Date: 13 Oct 92 02:04:45 GMT
Organization: ACUS Australian Centre for Unisys Software, Sydney

keck@castor.trl.OZ.AU (Brian Keck) writes:

>What I have in mind are tools that take up where lint leaves off,
>for C primarily, but also C++ & Eiffel.

There is an excellent such product for Eiffel. It is called a compiler ;-)
Seriously, tools like lint are unneccessary where the language design
and compiler are designed to catch these kinds of inconsistency. There is
no reason why lint cannot be built into even a C compiler. For example
the Unisys A Series C compiler has lint built into it. If you are porting
a program that is so dirty, then you can reset lint as a option.

So the answer to your question is that better language design takes up
from where lint left off.
-- 
Ian Joyner  ACUS (Australian Centre for Unisys Software)    ian@syacus.acus.oz
"Where is the man with all the great directions?...You can't imagine it,
 how hard it is to grow, Can you imagine the order of the universe?" ABWH
Disclaimer:Opinions and comments are personal.
Newsgroups: comp.lang.eiffel
From: Ari.Huttunen@hut.fi (Ari Huttunen)
Subject: Re: Freeware, Sather, types and other questions.
Organization: Helsinki University of Technology, Finland
Date: Wed, 14 Oct 1992 23:50:09 GMT

In article <Bw2C0v.LE3@dcs.ed.ac.uk> pdc@dcs.ed.ac.uk (Paul Crowley) writes:

! I know about Sather and it seems very nice indeed.  One thing I found
! strange: it allows you to assign to a variable from a supertype of
! that variable, assuming that you know what you're doing.  Presumably
! if you get it wrong and you subsequently try to invoke a method not
! available on the supertype, Bad Things Happen. 

You can test this at the run-time, and you can also test the type 
of objects at run-time, so this is not really a problem. Anyway, the
next version of Sather (1.0) will be much different. Currently it
seems that you will be able to say:

	typecase x:=(a+b)*c
	when A then  ...if the type of 'x' is 'A'...
	when $B then ...if the type of 'x' is '$B' or a subtype thereof...
	else ...otherwise...
	end;

Disclaimer: Don't blaim me if this doesn't happen. Things change rather
            rapidly and I'm really not a member of the development team...

ps. Try to guess what these do:

	for e:=array.elements loop res:=res+e end;
	for i:=array.indices loop array[i]:=2*array[i] end; 

--
...............................................................................
Ari Huttunen   			       Any similarity to other alien life forms
				          is purely coincidental.
					      <Alien 3 misquote>