HDTenEightyP/NetNews huggingface dataset:
From: burchard@horizon.math.utah.edu (Paul Burchard)
Subject: Re: Pros and cons of C++
Organization: University of Minnesota
Date: Thu, 28 Jan 1993 02:17:54 GMT

In article <1993Jan26.145454.21534@midway.uchicago.edu> dave@alex.uchicago.edu  
(Dave Griffith) writes:
> In article <C1G9H4.HsA@unix.portal.com> samantha@shell.portal.com (Samantha Atkins) writes:
> >No object language I am aware of does a message based much less a decent
> >semantic based check.  So in what way has safety been assured really?
>
> What I want to see, is a language 
> where protocols and implementations are definable independently.  Protocols
> may for a heirarchy by subtyping, implementations form a heirarchy by
> inheritance.  Inherita 
nce can thus be just a form of code-sharing, possibly
> not the only such form in the language.

You're in luck---you've just described Objective-C.  It supports Protocols, which provide both compile-time and run-time type-checking, verifying that an object or class implements a designated set of messages.  Protocols can incorporate ("inherit") any number of parent Protocols, while the class hierarchy (implementations) does not support multiple inheritance.

Someone wrote to this newsgroup a few weeks ago about a project he was working on to add what he called ``signatures'' (essentially the same thing) to C++.  While C++ needs new features like Minneapolis needs cold weather, this seems like a good idea.

(Note: Protocols aren't yet available in the current version of
GNU Objective-C; NeXT's latest changes haven't been folded in yet.)

In article <MUTS.93Jan12100059@PMCS.estec.esa.nl> muts@estec.esa.nl (Peter Mutsaers) writes:
>The implications can be complex, but that is more due to OO than to
>C++ in particular. But it pays for most applications.

I am always amused by these arguments that the complexity of C++ is due to some villain like OO or C compatibility, since Objective-C provides such a ready counterexample.
--
--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

























Newsgroups: comp.object
From: hasko@heeg.de (Hasko Heinecke)
Subject: Re: Classes are procedures, objects are closures in class based OO languages
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
Date: Thu, 28 Jan 1993 14:51:18 GMT

In article <PCG.93Jan22170223@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>
>on [Tue, 19 Jan 1993 23:59:21 GMT] I had written a little article to
>show how (class based) OO was born out of making it possible to have
>multiple persistent instances of procedure contexts (closures), to
>explain my short description:

I didn't read this article, but please tell me: where do you get your
information from? If you are using Simula as a reference, I can tell
you: this is the main difference between Smalltalk and Simula.

Smalltalk - and thus OO :-) - was born out of the need to simplify
modeling reality.

Hasko Heinecke

-- 
+-------------------------------------------------------+
| Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| I _never_ mean what I say - and nobody else does...   |
+-------------------------------------------------------+
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: FAQ  Part 1 (of 2)
Date: 27 Jan 93 16:17:14 GMT
	<DAVIS.93Jan15140421@passy.ilog.fr>
Organization: University College of Wales, Aberystwyth

>>> On 15 Jan 93 13:04:21 GMT, davis@passy.ilog.fr (Harley Davis) said:

Davis> In article <PCG.93Jan14154212@decb.aber.ac.uk> pcg@aber.ac.uk
Davis> (Piercarlo Grandi) writes:

pcg> [ ... ] in Smalltalk and Lisp based systems variables are objects
pcg> in some Dictionary/oblist/package which denote other objects; in
pcg> more conventials languages they are labels for reference values.

Davis> In SmallTalk this might be true (I don't know) but in almost all
Davis> modern Lisps, lexical variables have exactly the same status as they
Davis> do in other languages:

I know this, but almost all modern lisps are CL and Scheme (and your
delightful but obscure favourite, ISO Lisp/TELOS). I have this old habit
of thinking of Lisp as 1.5 and descendants... I tend to think of
lexically scoped Lisps as of descendants of Scheme (well, yes, to me CL
is a huge fat Scheme dialect ;->).

Davis> they are merely names for a temporarily assigned memory location,
Davis> stack location, or register.

I.e. labels for reference values (they are labels for the 'address' of a
memory location or a register').


(This posting was really redundant, but what the heck, we must all give
our little contribution to justifying those fat T3 backbone lines :->).
Newsgroups: comp.object,comp.lang.c++
From: harvey@opl.com (Harvey Reed)
Newsgroups: comp.object
Subject: Re: Maintenance and OO
Date: 27 Jan 93 15:26:30 GMT

pkeddie@axion.bt.co.uk (Paul Keddie) writes:


>...
>1) Are 00 programs harder to maintain than normal functional programs?

IMO a well written OO program is much easier to maintain.

>2) Do maintainers need to adopt new approaches to maintenance for 00
>   programs?. For example, I've found trying to track function calls can

Traditional practices dictate that an employees performance is measured by
the bulk of code produced in a development cycle. Using traditional
practices in OO development can lead to programs that are incapable of
being maintained.

Once employers realize the folly (and some do!), they will let the
developers spend more time designing, and so on with the
obvious benefits. I am fortunate to have found such an employer.

Suppose a well written (and designed!) C++ program falls into your lap
as a maintainer. The first thing to do IMO is to thoroughly understand
the design. Maintaining OO (and C++) requires a more global understanding
of the system than with C.

I think this is a result of the fact that well designed OO packages
(class, whatever) tend to get reused over and over, so the end result
is that fixing a line of code can have impact throughout the system.

>   lead to dead ends if you come to a call to 'Handle' in an event-driven
>   program. Is my approach wrong?

IMO debugging an OO system is more tedious than traditional C. The key
here is to have small unit tests for each package, class whatever. If
there is suspicious behavior, go back to the unit tests first and see
if they were comprehensive enough, also the unit tests might give
you clues as to how the "live" system differs from the unit test. My bias
is to use debugging as a last resort. This bias has served me well.

>3) Are there more difficulties because of C++ rather than the 00 paradigm?

Refer to the endless arguements on comp.lang.c++

>4) Is badly written C++, 00 programs worst than the equivalent C programs?

A badly written C++ program can be your worst nightmare. A well written
C++ program is a dream to work with. C falls in between somewhere.

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

I've been using C++ since 1987-88, Modula-2 before that. I enjoy the
C++ language, but understand peoples frustrations. I would never 
go back though.

Once you get the hang of it, OO and C++ are *very* productive. The
key (as many people will tell you) is:

1. There is no substitute for up-front analysis and design

2. There is no substitute for building quality in up-front

3. There is no substitute for catering your standards toward
   the people who will be maintaining your system.

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

If you turn out to have more questions specific to C++, you should
move your post to comp.lang.c++



-- 
++harvey
===========================================================================
internet:       harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice/fax:      617-965-0220    /  617-965-7599
Newsgroups: comp.object
From: santas@inf.ethz.ch (Philip Santas)
Subject: Re: Re: FAQ  Part 1 (of 2) [ polymorphism or latent typing? ]
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Fri, 22 Jan 1993 21:19:05 GMT

In article <KERS.93Jan22095935@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>
> Meyer describes [p73, OOSC] an
>``entity'' as the object-oriented equivalent of a variable. In Eiffel, entities
>of a class hold references to objects.
>Thus, in at least this one case, polymorphism is a property of *entities*, not
>*objects*. 

Any particular reason why the original term ``variable'' is not used?

Philip Santas

  "In an evolving universe those who stand still are really moving backwards"
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch                                Philip Santas
Mail: Dept. Informatik                     Institute of Scientific Computation
      ETH Zurich                          Swiss Federal Institute of Technology
      CH-8092 Zurich                                  Zurich, Switzerland
      Switzerland
Phone: +41-1-2547478
      


From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Fri, 22 Jan 1993 09:59:35 GMT
Subject: Re: Re: FAQ  Part 1 (of 2) [ polymorphism or latent typing? ]
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.object

In article ... Bob Hathaway <objsys@netcom.com> writes:

   Or even better, try Eiffel [Meyer 88:p224] ""Polymorphism" means the ability
   to take several forms.  In object-oriented programming, this refers to the
   ability of an entity to refer at run-time to instances of various classes.
   In a typed environment such as Eiffel, this is constrained by inheritance."

and later:

   I think you're the one inflicting confusing terminology.  Everyone in recent
   history seems to define polymorphism as a property of objects (Stroustrup,
   Meyer, Booch, ...) 

Your quote from Meyer (above) shows clearly that, for Meyer, polymorphism is a
property of *entities*, not *objects*. Meyer describes [p73, OOSC] an
``entity'' as the object-oriented equivalent of a variable. In Eiffel, entities
of a class hold references to objects.

Thus, in at least this one case, polymorphism is a property of *entities*, not
*objects*. 

   Lets look at the real world.  There is some class of objects, B, that can
   have many forms, lets assume as given the case that they don't change once
   a particular form is taken.  Now lets define some kinds of forms that a B
   can take, and call these classes D1, D2, ...  Now take the case of where any
   of the D's can occur.  In the sciences, B is refered to as "polymorphic" or
   as a "polymorphic object".  I can declare a B object that can stand for any
   of the D forms.  Since B can take on many differing forms, it is defined as
   "polymorphic".  The property that B can assume different forms (and not the
   ability to become other forms, as in metamorphosis) is the canonical use of
   the term polymorphism.  So sorry, it doesn't look as though structural and
   behavioral replacement (or a becomes facility) is the standard usage of the
   term polymorphism.

Not in the natural sciences, perhaps. Different fields of inquiry are
characterised by different linguistic perversions, sorry, developments.
How else could it be? There are different clusters of people doing the 
work, with their own linguistic history, and the subject matter itself
suggests its own metaphors.

It might be ``standard'' to use polymorphism this way outside computing,
but it's ``standard'' to use ``bit'' to mean a little piece of something,
``core'' to mean the centre of something (usually -- in my experience -- an
apple), ``pipe'' to mean a physical tube through which (generalised) fluids
flow or something to smoke tobacco in, and ``function'' to mean a bit of a do.

--

Regards,    | "You're better off  not dreaming of  the things to come;
Kers.       | Dreams  are always ending  far too soon." - Caravan.
Newsgroups: comp.object
From: chandram@ece.scarolina.edu (Rajagopal Chandramohan)
Subject: What the hell is "IMO" ?
Organization: USC  Department of Computer Science
Date: 28 Jan 93 01:46:13 GMT

Would some kind soul explain what does IMO stand for? I have been
trying to guess the meaning from context without luck. Thanks.

Rajagopal
Newsgroups: comp.object,comp.software-eng
From: whmurray@cibecue.az05.bull.com (William H. Murray)
Subject: Re: Writing Windows Applications in Ada?
Organization: Bull HN Information Systems, Inc., Phoenix Product Division
Date: Mon, 25 Jan 93 15:33:58 GMT

I'm certainly no guru with ada tasking, but I do know that the
ada83 tasking model does not have hard time constraints, so I am
also confused by this. My current DOS ada compiler has a "preemptive"
runtime and a non preemptive runtime. (I don't know which one it is
validated with, and don't really care since I don't use tasking at the
moment. I guess validation may require that a single task gets dispatched
to "some time". This may be hard to ensure if another task is in a loop.
 
For all you vendors out there, who is going to support windows NT and when.
And now the killer question. If you say you can not validate on 3.1 due
to tasking restrictions, does this also mean that ada executables will not
be able to run on win32s?? Paying customers want to know??

Bill Murray  whmurray@cibecue.az05.bull.com

Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Re: FAQ  Part 1 (of 2) [ polymorphism or latent typing? ]
Organization: Object Systems
Date: Sat, 23 Jan 1993 06:22:35 GMT

In article <KERS.93Jan22101155@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>In article ...Bob Hathaway <objsys@netcom.com> writes:
>
>   Since Strachey defined parametrically polymorphic
>   functions (functions parameterized by objects of different types), the
>   formal parameters assume many forms and can be referred to as polymorphic.
>
>Yes; and formal parameters are not objects. (Digression to meta-discussion
>about how the compiler might treat the code would be irrelevant.)

Actually, in C++ formals are objects.  As I already discussed, parameter
assignment is considered an initialization of a declaration, an object
declaration.  If the declarator specifies a reference or pointer *object*, this
object is polymorphic.  If you want to argue that in some languages, such as
Smalltalk, that names or entities are not objects but denote them, thats a
subtle difference, since pointers and references (or the names or entities)
*are* objects in some languages, simply objects that denote other objects.
You won't be able to program in languages with pointers if you don't
understand this.  Anyway, I see the point that the denoted objects are the
ones of *primary* interest, and perhaps I should change my definition to
emphasize that the references are polymorphic and not the interesting (?)
objects themselves (sorry piercarlo).

>   I think you're the one inflicting confusing terminology.  Everyone in recent
>   history seems to define polymorphism as a property of objects (Stroustrup,
>   Meyer, Booch, ...) 
>
>I think this is because you have conflated the notions of ``objects'' and
>``variable'' (or reference, or pointer, or whatever).

This is completely wrong because it is out of context.  Piercarlo was arguing
that either procedures (??) or objects "becoming" other objects defines
polymorphism, and that is what I was disagreeing with.  He argued against
Meyer, Booch, and me completely - names, entities, objects and all - stating
our intention of polymorphism is wrong and should be referred to instead as
"latent typing".  I hope I've presented enough information to show *we* are
correct!  And his anachronistic views on the functional implementation of the
object model and then using a functional view of values on top IMHO seems to
have confused the ganoozga's out of everyone in this newsgroup.  At least
I push the object model [and history has shown both you and piercarlo often
haven't, if I may take sides].

Regards,
bob
objsys@netcom.com

I'm still wondering if there are any other true OO believers out there, its
getting lonely...
Newsgroups: comp.object,comp.software-eng
From: berczuk@space.mit.edu (Steve Berczuk)
Subject: Re: Why and how do organizations select O-O approach to S.E.
Organization: MIT Center for Space Research
Date: Thu, 21 Jan 1993 17:27:53 GMT

In article <1jlic1INNvjn@emx.cc.utexas.edu>, kalakota@emx.cc.utexas.edu (Ravi Kalakota) writes:

|> 1. What are the factors that were considered and evaluated before you decided
|> to select an object oriented approach to software engineering?
|> 
In the 2 projects I have worked on so far, the primary factor in selecting a
methodology was (yes, this is serious) what methodology the (novice, until the 
time of taking a course in OO)  WHICH ONE THE DECISION MAKER SAW
 in the first course that he took on Object-orientation.

Both times there were others in the project who had been building OO systems for at
least a few years and were at least familiar with some of the OO methodologies, and
these experienced people would find the choice to be wrong for various reasons.

When I was working at Kodak, someone had taken a course that used teh Wirfs-Brock
book -Designing object -oriented software, and the general opinion was (Please,
let's not get into arguments about methodologies-- these are just examples) that
while is was a great methodology for pedantic purposes, the notation, etc got in
the way with the expression of design ideas. We still used wirfs brock ( Well, what
we did was retro-fit our designs to use the right symbols when documents were
due...)

In another project elsehwhere, someone took a course that used Rumbaugh, (which is a better
methodology, but one that tended to confuse those new to c++ on our project. It was
easy to describe systems where the relationships between objects and their methods
was fuzzy- ) and that is the one that all teh documents were written in.

|> 2. What impact does the selection of object oriented methodology have on
|> the project sucess, customer satisfaction and learning for future projects?
|> 
Using the wrong one and being insistent on it can be painful. The methodology
should be used to facilitate the DESIGN process as WELL as the documentation
process. Probably the biggest problems arise from taking the phrase "We'll use the
XXX methodology" to mean "We'll use the symbols in the XXX methodology" rather than
using the methodology to explore the system.


-- 
Steve Berczuk			berczuk@mit.edu		
MIT Center for Space Research	(617) 253-3840

Newsgroups: comp.object
From: paj@jojo.Rational.COM (Peter Jeffcock)
Subject: Re: example application software from Booch
Organization: Rational
Date: Fri, 22 Jan 1993 18:25:50 GMT

frerk@loophole.tk.telematik.informatik.uni-karlsruhe.de (Frerk Meyer) writes:

Rational are now the exclusive distributors for Palladio's OSD product.
It is now called Rational Rose for Windows. The correct price is $495 US
in the United States. You can order the product or obtain a demo disk
by calling 1-800-767-3237 or (408) 496-3700.

Peter Jeffcock
paj@rational.com

>Perhaps it's not exactly what you are searching, but we got a
>demo version of 'Object System/Designer' for Windows by Palladio Software
>Corporation. It's nice and impressive.

>Palladio Software Corp.
>16535 West Bluemound Road Suite 360
>Brookfield, WI 53005
>Fax: 414-789-5191
>Free: 800-437-0019

>Price of the full version is 349$ US

>I'm in no way related to Palladio
>-- 
>Frerk Meyer <frerk@tk.telematik.informatik.uni-karlsruhe.de>  -+
>Portnoy@irc             "Do the ride thing!"                 o>o
From: king@cs.uq.oz.au (Paul King)
Newsgroups: comp.object
Subject: Re: active objects (was: rethinking the Object Paradigm)
Date: 24 Jan 93 23:56:43 GMT
Reply-To: king@cs.uq.oz.au

In <BUMESH.93Jan21134932@puma.cat.syr.EDU> bumesh@cat.syr.EDU writes:

>>>>>> On Wed, 20 Jan 1993 17:19:36 GMT, cjmchale@dsg.cs.tcd.ie (Ciaran McHale) said:

>Ciaran> I had used the term "active object" to refer to languages such as POOL
>Ciaran> (Pierre America) or Eiffel || (Denis Caromel) in which an object has a
>Ciaran> single thread. This thread is used to both (i) schedule the order in
>Ciaran> which messages/invocations where to be serviced, and (ii) service them
>Ciaran> itself. Since there is just a single thread inside the object, all
>Ciaran> operations execute in mutual exclusion. Actually, now that I think of
>Ciaran> it, I think I used the term "single-threaded, active objects" to refer
>Ciaran> to such languages.

>I don't see how threads really make any difference. What we really
>should be concerned about is the mapping of activity to CPUs. Given a 
>single CPU machine it does not make any sense to have an object which
>can have multiple threads at all...

What about the situation where my object needs to communicate with
several others via a slow mechanism (perhaps RPC).  If I have multiple
threads I can kick off all the RPCs in parallel.  If I only have a single
thread I have to do this in a serial fashion.

>Ciaran> Does anybody have a definitive definition of what "active" means?
>Ciaran> Failing that, what are the different definitions which the other
>Ciaran> participants are using?

>Active should essentially mean the ability to perform computation.

I think the term active object should apply to objects with the ability
to initiate some computation of its own accord.  It only makes sense to
define activity in terms of some interface.  If I have some interface
between a client and a server then, generally, the client is the active
partner wrt that interface.  That server just sits there waiting until
the client asks it to do something.  If the server uses other service
interfaces to satisfy the client request, then it is still not being
active wrt the original interface.

The usefulness of identifying an operation as active (or passive)
is in defining type compatibility rules.  [You need type compatibility
over your class hierarchies if you want to use them polymorphically.]
For the standard active-client/passive-server style of operation the
weaker-pre/stronger-post requirement is necessary for type compatibility.
[This is what the Eiffel type system tries to enforce and is the main
rule for so-called `operation' refinement.]
For passive-client/active-server operations, a stronger-pre/stronger-post
requirement is needed. [Not considered by Eiffel, sometimes referred
to in `process' refinement literature.]

Cheers, Paul.
--
Paul King							       _-_|\
Dept. of Computer Science, Univ. of Queensland			      /     X
Queensland, Australia, 4072					      \.--._/
king@cs.uq.oz.au (ACSNET)					           v
Newsgroups: comp.object