HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.object
Subject: Re: OOP not GUT of programming?
Date: 6 Oct 1992 05:31:38 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

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.

I've seen some excellent examples of object-oriented compilers and text
editors on Symbolics Lisp Machines.

Compilers: The code generator has classes for different back ends.  Their
lex/yacc-like system has classes for different types of parser technologies
(LALR, LR, etc.).  Objects in the parse tree, parser states, etc. are all
implemented using classes.

Editors: The editor is Emacs-like.  It has classes for buffers,
sections of buffers, and major modes.  When you switch to a buffer, it
sends a message to its major mode telling it to initialize command tables,
editor variables, etc.  The different buffer classes can implement
different data storage techniques (for instance, Dired buffers maintain
references to file names alongside the displayed text).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Why is garbage collecting considered intregral to OOPS?
Date: Sun, 27 Sep 92 08:16:30 GMT
Organization: Object Systems

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.  

And in retrospect, the original poster's contention about problems caused
by loops only occurs in the presence of nested pointers at some level.

>I would love to try a programming language
>that permits the definition of pointers with user-defined 
>semantics.

I have.  Are you sure?

bob
objsys@netcom.com
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
From: nagle@netcom.com (John Nagle)
Subject: Re: comparing object-oriented platforms
Date: Sat, 26 Sep 92 17:36:44 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

mwu@orion.oac.uci.edu (Matt Wu) writes:
>I'm currently evaluating several object-oriented development platforms
>and I was wondering if any of you would like to share your opinions on
>platforms that you prefer or know about.  It'd be especially useful to hear
>comparisons between different platforms (for instance, Eiffel v. Smalltalk).

      The language situation is roughly as follows:

	Ada		Big, no inheritance, some tools expensive but do
			exist.  Many books on language available.  Many
			free libraries available.  DoD standard.
	C++		Big, multiple versions of language, unsafe.
			Tools widely available.  Many books available.
			Most popular choice.
	Modula-2	No classes or inheritance.  Many books.
			Many implementations.  Solid, but limited.
	Modula-3	Limited interest - one free compiler, one book.
			Adds classes to Modula-2.  Less used than
			Modula-2.  
	Eiffel		Limited interest - one or two compilers, one book.
			Less used than Smalltalk, C++, Ada, or Modula-2.
	Smalltalk	Slow execution, good tools.  Multiple books
			available.  Clean language.  Good for experimental
			work.  Avoid pure-interpreted versions if speed
			at all important.
Newsgroups: comp.object
From: chambers@klamath.cs.washington.edu (Craig Chambers)
Subject: Re: comparing object-oriented platforms
Reply-To: chambers@cs.washington.edu
Organization: University of Washington
Date: Tue, 6 Oct 92 00:36:02 GMT

In article <TMB.92Oct4182305@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
|> 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.

Ad hoc ("OO-style") polymorphism is not more restrictive than
parametric ("Milner-style") polymorphism; the two are incomparable in
expressive power.  Certainly things like arrays of mixed integers,
rationals, and floats cannot be statically-typed in ML.  To be really
effective, statically-typed languages should support both kinds of
polymorphism.  That's why good statically-typed OO languages like
Trellis and Eiffel support both subtyping and parameterized types
(Trellis actually being type-safe throughout).  ML only supports the
latter, with kludges to handle overloading of a few built-in
operators.  Haskell's type classes work better in this regard, but
still do not match real OO dynamic overloading.

Your comments on some of the things that SML's functors can do (e.g.
the group/field example) are tasty food for thought, though.

-- Craig Chambers
Xref: sparky comp.object:3800 comp.lang.smalltalk:1987 comp.lang.eiffel:1206
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: Sun, 27 Sep 92 08:47:48 GMT
Organization: Object Systems

In article <KERS.92Sep22160323@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
> * whether type *checks* are performed at compile or run time.
>
> * whether type *information* ia available (to the programmer) at compile or
>	run time.

Interesting, but how can you have type checks without type information?
There is a dependency here.

>   I assumed the confusion was over matters such as
>   languages providing only static typing (with virtuals) can only perform
>   static inclusion polymorphism and not the dynamic variety, meaning that
>   multi-methods cannot be supported. 
>
>By the (implied) term ``dynamic polymorphism'', do you mean the free-for-all
>latent typing exemplified by Lisp and Smalltalk?

I meant dynamic method signature selection (as with multi-methods) as noted
in the previous article and above.

>...[On a static typing definition]...
>I think I agree. HEY EVERYONE GET A LOOK AT THIS -- DOLLIN JUST AGREED WITH
>HATHAWAY. DEATH OF THE NET PREDICTED. FILM AT ELEVEN.

Hopefully not before tonight's postings get out; this once a week stuff
is rough!

>   Amazingly enough, Coplien blunders pretty bad in this area.  The bottom of
>   page 121 is too painful to reproduce.  He claims C++ compilers place a 
>   hidden type field (unavailable to programmers) in objects whenever virtual
>   functions  are present in its class and that this type is used at run-time.
>   This is obviously false and can lead to the kind of confusion I've been
>   trying to clear up.  Maybe his compiler uses type tags, switches, and 
>   thunks instead of vtables?-)
>
>Isn't this the usual implementation of classes-with-virtual in C++ ? The vtable
>(to which you refer yourself) is just such a ``hidden type field''. Granted,
>one doesn't (in general) look at it to deduce the actual type of an object, but
>that's what it is.

Thats pushing it in my opinion (but I'm sure was Coplien's intention).
Either function pointers *or* type tags and cases can be used; there's
often debate over the choice between the two (especially in OO).  Coplien
referred to his section where explicit types were declared by the
programmer and then contended thats the approach compilers use and
that isn't true; type tags do not implicitly exist in C++, function
pointers do.  Again if you stretch it far enough maybe but I felt his
presentation was questionable (i.e. that some people would leave feeling
C++ objects really do have type fields but they (almost always) will not;
just a vtable pointer).

Down to under 100 lines, Chris; we must be making progress...

bob
objsys@netcom.com
Newsgroups: comp.object
From: bhonsle@sf49ers.iss.nus.sg (Shailendra K Bhonsle)
Subject: Graphical browser for OO systems
Organization: Institute of Systems Science, NUS, Singapore
Date: Tue, 6 Oct 1992 07:19:51 GMT

Hi,
I am desperately looking for some graphical browser for objects in OO systems.
Does anyone know of any such ftp'able or commercial product. Does it work with
X-Windows, Motif etc.

Will looking into literature for OODBMS help?

Thanks for your help.


Shailendra.

email: bhonsle@iss.nus.sg


-- 
Xref: sparky comp.object:3808 comp.lang.smalltalk:1994 comp.lang.eiffel:1210
From: smith@ctron.com (Larry Smith)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: comparing object-oriented platforms
Date: 1 Oct 92 18:17:28 GMT
Reply-To: smith@ctron.com
Followup-To: comp.object
Organization: Cabletron Systems, Inc.

In article <23741@alice.att.com>, garry@alice.att.com (garry hodgson) writes:
>In article <1992Sep28.024059.25761@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:
>>C++ compilers may be better for
>>died in the wool C programmers who are scared to
>>venture to far from the nice little C hole they have
>>dug theselves.

>Yeah, I just spend all day cringing in my office, uh, hole, praying
>I will never have to learn anything or have an original thought again.
>Pssst.  Don't tell my management.

Don't be so quick to be so sarcastic, Garry, you may well be an exception.
I've worked with oo systems for years and have dealt with (and implemented)
a number of oo languages, but my bread-and-butter is C++ and I've seen it
up close and personal in several environments, and I have to agree with Kenny's
opinion.  C++ _does_ permit programmers to be lazy with respect to designing
object-oriented systems, and although it is possible to write clean, modern,
object-oriented systems in C++ I've yet to see anyone do so.  The reason is,
I believe, because too many people just see it as an extended C, and refuse to
make that paradigm shift to object-oriented thinking.  A great many programmers
_don't_ have original thoughts, and _are_ scared to venture into new territory.
That's is normal human nature, and it occurs in programmers quite a lot more
than we like to admit.

I've even seen piles of code written using C++ object which was "object
oriented" only by courtesy - the objects were not well thought out, the
hierarchies were a bad joke and the objects kept mutating for revision after
revision.  Now, a lot of this is just plain bad design in general - but it is
certainly true that permitting good design is not the same as encouraging it.
C++ provides little encourgement to move to modern software design, and I've
see retread C coders to terrible things with it.

Larry Smith (smith@ctron.com)  No, I don't speak for Cabletron.  Need you ask?
-
How about we all do something reasonable?  I bet that'll confuse 'em!
Xref: sparky comp.object:3863 comp.lang.smalltalk:2049 comp.lang.eiffel:1236
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
From: tlai@cs.toronto.edu (Tony Wen Hsun Lai)
Subject: Re: comparing object-oriented platforms
Organization: Department of Computer Science, University of Toronto
Date: 30 Sep 92 16:22:46 GMT

In article <1992Sep29.043418.16848@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:
>In comparison to Eiffel I would like to know:
>
>Does Modula-3 have inheritance/multiple inheritance?
>
>Which leads to the question does Modula-3 have
>polymorphism and dynamic binding?
>
>Is the garbage collector an incremental one , operating as a coroutine.
>Can the garbage collector be tuned from a running system, so that 
>the collection frequency and period is managed by an application or a user.
>Although is really an issue of an environment rather than the language
>per se. I agree it is certainly important.

Um, I think Modula-3 has (single) inheritance, polymorphism, and dynamic
binding.  Traced types are automatically garbage collected, and untraced
types must be allocated and deallocated by the programmer.
From: dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: comparing object-oriented platforms
Organization: Ecole Polytechnique de Montreal, Canada
Date: Mon, 28 Sep 1992 14:04:46 GMT

In article <-t!p#_a.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:


>	   Modula-3	Limited interest - one free compiler, one book.
>			   Adds classes to Modula-2.  Less used than
>			   Modula-2.  

I dont want to start a language war here (it already started, a dozen
replies already came out on John Nagle's post), but the extensive libraries
available ( X graphical user interface, read/write for objects) for free
with DEC SRC Modula 3 should be mentioned. Moreover it has garbage
collection AND preemptive multi-threading (all the libraries are thread
safe), which none of the others mentioned (C++, Eiffel, SmallTalk...) have.
Threads are quite useful for user interaction and client-server
applications.

--
---------------------------------------------------------------------

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

---------------------------------------------------------------------
From: ameesh@lsil.com (Ameesh Desai)
Newsgroups: comp.object
Subject: Re: Comparison of OODBMS
Date: 30 Sep 92 17:49:38 GMT
Reply-To: ameesh@lsil.com
Organization: LSI Logic Corporation


I have seen a number of requests for info regarding ODBMSs on the net. 

I feel the reason there is a lack of response from people who
have done such evaluations in the past is the fact that most ODBMS vendors
require us to sign Non-Disclosure Agreements. This is also the reason that 
I am unable to contribute to this discussion !

Ameesh
---
______________________________     o__            
| _   /|     Ameesh Desai     \    ,>/_                              
| \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
| =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
|____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.object
Subject: Re: comparing object-oriented platforms
Date: 6 Oct 92 02:55:10 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: burchard@horizon.math.utah.edu's message of 4 Oct 92 22:57:10 GMT

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

   > 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.

   You're correct; I thought you were referring to hierarchical OO
   polymorphism.

   Could you explain what "Milner polymorphism is"?

Milner-style polymorphism is roughly what you get with C++ templates.
That is, you can write code that works with any consistent combination
of types, values, functions, and "methods".

   Is it anything
   like the Objective-C "protocols" I mentioned, where you can, as
   part of the compiler's typing system, declare an object to respond
   to a certain set of messages?

No, it isn't the same, and I agree that this is cumbersome in several
existing OO languages. However, the reason is not the presence of
static type checking per se.

You can express this concept both in terms of OO primitives (e.g.,
what C++ provides) or closures (e.g., what Lisp/CLOS, Smalltalk, and
SML provide). I personally find the use of closures for this purpose
much more elegant.

In an OO language, you can write your function in terms of some
abstract base class that has the set of messages you want, and
encapsulate existing objects and forward the required methods in
derived classes. If you happen to have templates, you can even make
return types work out this way. Because this is so cumbersome, most
people don't seem to bother, but you don't need compiler support to do
it.

	struct XY {
		int x() = 0;
		int y(int) = 0;
	};

	int f(XY &frob) {
		return frob->x() + frob->y(3);
	}

	struct A_as_XY {
		A *a;
		A_as_XY(A &a):a(&a) {}
		int x() { a->foo(); }
		int y(int r) { a->something(r,r); }
	}

	int g(A &a) {
		A_as_XY a_as_XY(a);
		return f(a_as_XY);
	}

In a language with closures, you create a structure containing just
the functions ("protocol", "methods") you need, closed over the
appropriate "objects". This can be done on the fly and works quite
well. In fact, in a functional language with a Milner-style type
system, this is so trivial that most people don't even think about it:

	fun f(x,y):int = x() + y(3);
	fun g(a) = f(A.foo(a),A.something(a));

(You can think of "A.foo(a)" as the equivalent of "a->foo" in C++,
i.e., the method itself.)

While I generally don't subscribe to the notion of "shorter is always
better", I think this particular technique, namely wanting to have
lots of small, minimal "protocols", is frequent and useful enough that
the C++ solution is too cumbersome.


					Thomas.
From: burandt@ira.uka.de (Axel Burandt)
Newsgroups: comp.object
Subject: Looking for verification calculi for OOP's
Date: 1 Oct 1992 08:44:22 GMT
Organization: University of Karlsruhe, FRG
Distribution: world
NNTP-Posting-Host: i11s14.ira.uka.de



I already have posted a query about semantics and calculi for
OOP's about two month ago. There have been quite a lot responses
concerning semantics but nothing about calculi. 
Therefore my question:

Does anyone of you know about papers concering logical calculi
for OOP-Verification? 

I've in mind something like P.Americas work about POOL.
(Second Question: Is there any paper reflecting the "state of art"
 concernig POOL?)

Please sent your answers to the following adress

burandt@ira.uka.de

Thanks a lot

Axel Burandt
From: neil@ogicse.cse.ogi.edu (Neil Van Dyke)
Newsgroups: comp.object
Subject: OO Test Methods
Date: 30 Sep 92 06:40:46 GMT
Article-I.D.: ogicse.43417
Distribution: world
Organization: Oregon Graduate Institute, CS&E

Can anyone point me towards info on testing of OO systems?

Thanks,
neil@cse.ogi.edu

Xref: sparky comp.object:3773 comp.lang.smalltalk:1965 comp.lang.eiffel:1192
From: smith@ctron.com (Larry Smith)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: Simula info (LONG) Was(Re: comparing object-oriented platforms)
Date: 29 Sep 92 17:47:25 GMT
Reply-To: smith@ctron.com
Followup-To: comp.object
Organization: Cabletron Systems, Inc.

In article <KNUTO.92Sep29114902@katnosa.ifi.uio.no>, knuto@ifi.uio.no (Knut Omang) writes:
>    A good example is that Donald Knuth, which visited 
>    our site in 1972, asked for a copy of the compiler to use in the
>    basic programming courses at Stanford, but had to leave empty handed 
>    because of the price of the compiler!! He instead ended up with Pascal
>    for his courses.

What a concept.

In some parallel universe out there, UCSD Simula went up against C and Pascal
for dominance of the industry.  I wonder what happened?

Larry Smith (smith@ctron.com)  No, I don't speak for Cabletron.  Need you ask?
-
How about we all do something reasonable?  I bet that'll confuse 'em!
Xref: sparky comp.object:3817 comp.lang.smalltalk:2002 comp.lang.eiffel:1217
From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: comparing object-oriented platforms
Date: 2 Oct 92 07:41:08 GMT
Organization: AT&T

From article <1992Sep30.204650.10038@bony1.bony.com>, by richieb@bony1.bony.com (Richard Bielak):
> In article <1992Sep29.235000.3583@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:
> 

stuff deleted

>>
>>   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.
> 

Anything that can call C can call C++ because C++ provides a mechanism
for defeating its mangling system ( extern "C" ). The only drawback
being that C++ will always look like C to Eiffel i.e. There is no way that
it can handle C++ objects or call their methods directly.

> 
> 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 -      |                                          *

Nick Hounsome
AT&T Network Systems UK
Xref: sparky comp.object:3738 comp.lang.smalltalk:1918 comp.lang.eiffel:1167
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: Sun, 27 Sep 92 07:53:44 GMT
Organization: Object Systems

In article <7+#prtg.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
>In article <1992Sep23.084548.14002@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>	class Base {
>>	protected: int i;
>>	public: int get()const {return i;}
>>	};
>>
>>	class Derived : public Base {
>>	public: void set(int j){i=j;}
>>	};
>>
>>	f(B&);
>>
>>Without downcasting, f cannot change the object. With downcasting,
>>and assuming the argument was really a Derived, then f can change
>>the object, that is, f can violate the protected interface of
>>the static type of its argument.
>
>I'm sorry, but you're mistaken.  f is not a friend and can only access public
>members of Base or Derived.  You're mistaken about outside access to
>protected base members - this is not allowed in C++.

Opps, I just noticed the semantics of Derived::set.  Since Derived objects
are supposed to be able to modify i this is Ok.  And Base desires this
or i wouldn't be protected.  There is nothing amiss here.  Sorry
for jumping the gun, the point I made about protected access is missing
the mark.

I showed why a strict base interface is usually undesirable to unworkable;
but perhaps you have a point, that this forced strict conformance could be
available if desired.  Can you provide a case?

bob
objsys@netcom.com
Newsgroups: comp.object
From: ian@bvsd.co.edu (Ian Nelson)
Subject: Re: comparing object-oriented platforms
Organization: Boulder Valley School District
Date: Thu, 1 Oct 1992 20:58:25 GMT

>>>C++ compilers may be better for
>>>died in the wool C programmers who are scared to
>>>venture to far from the nice little C hole they have
>>>dug theselves.

I'm not scared to go to other languages, it's just that another language
hasn't been good enough to make me switch.  I try to learn as many languages
as I can, but so far I haven't really encountered anything that has made me
want to stop using C.  




-- 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0
mQBYAiqtYqEAAAECWKssWKoVxXAu9S0A/rKepT1GT+PJjv+lHh1LyIYwI9gzfnoq
ydwdKIJ81qIDgkMAliSIOWZiGSYbXszmmspRDenRARe15NOEM36pGQAFE7ABh7Qc