HDTenEightyP/NetNews huggingface dataset:
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: O-O adoption, rejection
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Wed, 8 Apr 1992 15:52:51 GMT

inunn@hpb.hwc.ca writes:

>I recall hearing that Cognos Inc. in Ottawa, Canada had a large OO develop-
>ment project which they had to scrap.  Confirmation and reasons for should
>be sought after before using this information.

>Ian Nunn

There was a paper at the Symposium On Object-oriented Programming
Emphasising Practical Applications by Burton Leathors about this.
He said that the main problem was that they were building a very
large application (hundreds of programmers) with Eiffel, and the
Eiffel tool-set was not suitable for the task back in 1987-89.  He
mentioned management problems as a secondary problem, i.e. management
didn't put enough emphasis on design, and they waited for problems
to happen instead of trying to fix them before they happened.

Some non-participating observers have said that management problems
were probably the main cause of failure, and the problems with
Eiffel were secondary.  (These were NOT Eiffel users making this
claim.)  Rapid-prototyping does not mean that you can ignore analysis
and design, nor does it mean that you can get by without carefully
planning.  It just requires a different kind of planning.

It is a very interesting paper.  I recommend it.  At one time the
proceedings could be ordered from James TenEyck, Dept. of Computer 
Science, Marist College, Poughkeepsie NY 12601.

Newsgroups: comp.object
From: ogden@seal.cis.ohio-state.edu (William F Ogden)
Subject: Re: Encapsulation & Information Hiding....
Organization: The Ohio State University, Department of Computer and Information Science
Date: Wed, 8 Apr 1992 18:04:13 GMT

There is a key point about information hiding which, unfortunately, is
often overlooked. If you go back to the source of the concept you'll find
that there are really two companion papers which are necessary to understand
what Parnas is really getting at. The obvious one is the often cited `On the
Criteria to be Used in Decomposing Systems into Modules', but equally
important is `A Technique for Software Module Specification with Examples'.

Parnas' point was that you can't successfully achieve information hiding
without using specifications. If you don't want a client to look at how
you've implemented something, then you have to give him a satisfactory
alternative explaination. In two words then information hiding is about
having a good cover story.

Encapsulation mechanisms are an important technical improvement, but
judging from his examples, Parnas appears to have successfully used
information hiding in a FORTRAN system. Conversely, many programmers use
encapsulation mechanisms without any apparent attempt at information
hiding.

-- 

/Bill

Xref: sparky comp.object:1771 comp.lang.misc:1733 comp.lang.functional:494
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.object,comp.lang.misc,comp.lang.functional
Subject: Re: Types as first-class values?
Date: 16 Apr 92 09:58:48 GMT
	<STEPHEN.92Apr15015720@estragon.uchicago.edu>
	<plzjq!b.objsys@netcom.com>
Organization: University of Chicago CILS

|>But one of the required operations is membership test! What algorithm
|>do you propose to check if some function is in some set? That's why
|>you need types in the type theory sense: they don't barf on functions
|>considered as objects.
|
In article <plzjq!b.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) responds:
|I think the set "includes" operation above covers the membership test.
|Since functions are objects with a class (or meta-class), they can certainly
|have an equality operation, its just their signature in the simplist case.

So (+) = (-) = (*) = (/). What an interesting world! And *not* the one
of set theory, which requires that functions be compared
extensionally, a computational impossibility.
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: SUMMARY: Object-Oriented Software Maintenance (1200 lines)
Date: Sun, 12 Apr 92 21:59:54 GMT
Organization: Object Systems

In article <BEVAN.92Apr8100649@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>In article <9qpjhng.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
>   >In article <BEVAN.92Apr3165546@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>   >>Lumping "dynamic typing" in with "weak typing"/"typless" means you
>
>   Like it or not, the literature refers to purely dynamically typed languages
>   (such as Smalltalk) as typeless
>
>What literature?  I've read a fair few "OO" books, and I'm not
>particularly happy with the terminology used therein, as I mentioned
>in my previous message.  I specifically don't like any definition that
>cannot distinguish between FORTH and Smalltalk.  If the "literature"
>above can't do that, then _I_ wouldn't recommend that literature (at
>least on on that topic), no matter who wrote it.

Sorry, no refs with me, its just very common to see Smalltalk referred to
as typeless since I recall seeing the description in several places.  Also,
I don't know FORTH, so if you'd like intelligent responses to this issue,
please define FORTH'S dynamic/static facilities in a nutshell (i.e. what
binding is performed both before and during program execution).

bob
objsys@netcom.com

P.S.  Personally, I assumed the expression "typeless" was coined at time
      when static typing was the rule and dynamic typing the exception. So
      when an important new language was introduced without static typing
      (Smalltalk), it was metaphorically labeled "typeless", meaning not
      supporting types as most people understand and use them, instead of
      using a more descriptive and technically correct denotation such as
      "dynamically typed".
Newsgroups: comp.object
From: matthew@syacus.acus.oz.au (Matthew Smith)
Subject: Question: What OO tools are available?
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Thu, 16 Apr 1992 02:23:48 GMT

Newsgroups: comp.object,comp.lang.misc,comp.lang.functional
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Types as first-class values?
Date: Wed, 15 Apr 92 03:05:44 GMT
Organization: Object Systems

In article <7597@cui.unige.ch> oscar@cui.unige.ch (Oscar Nierstrasz) writes:
>Can anyone provide any references to programming languages that
>treat types as first-class values?

I believe the latest versions of CLOS may provide what you're looking for,
although I don't know if they can meet any static requirements and CLOS is
an extension of Lisp.

Our object-oriented OpenL seems to fit your bill, unfortunately the current
version is private and the new version is still under development and won't
be available for some time, Sorry!

In article <STEPHEN.92Apr14174618@estragon.uchicago.edu> stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
>In article <7597@cui.unige.ch> oscar@cui.unige.ch (Oscar Nierstrasz) writes:
>>  2. test whether a value satisfies it (and, if it does, be able to use that
>>     value in a type-safe way within the scope of the test),
>I'm a little confused by the notion of type you are looking for: the
>fact that you specify that you want a membership TEST suggests that
>you're thinking of a set theory rather than a type theory at all -
>types are properties of the expressions, not the values, *even when
>the types are values themselves*.

If by value he means object in the OO paradigm, this makes perfect sense as
in Modula-3's typecase statement.  So, a construct should be able to
determine if an object is a member or instance of some class, and if so,
perhaps interact with that object in a statically typed (safe and efficient)
way.

>Languages that provide first-class sets? I can't think of any; in
>fact, I'm not sure how you could do that. Unless you restricted
>yourself to small finite sets a la SETL, most of your primitives would
>be too expensive (the advantage of the type-theoretic approach is that
>while compilation may fail to terminate unexpectedly, a successfully
>compiled programme won't misbehave in that way).

Since set operations are quite small (add, delete, includes, ...), I don't
see what is so difficult, almost any representation seems to suffice and
if you need a set, you'll have to incur the expense anyway.  But I do agree
that small simple sets (if not all sets) should be implemented as
efficiently as possible whether provided by a programming language (Pascal,
Modula) or library (Smalltalk).

Cheers!
bob
objsys@netcom.com
Newsgroups: comp.object
Subject: Information Sought on Object Interest Group (U.K.)
From: scp@bse.com (Shelley C. Peacock)
Date: 14 Apr 92 19:06:39 GMT
Reply-To: scp@bse.com (Shelley C. Peacock)
Organization: Berard Software Engineering, Inc.
Keywords: Object Interest Group
Summary: looking for addresses and contacts in the OIG (U.K.)
X-Mailer: uAccess - Macintosh Release: 1.5v3


I am looking for information about the Object Interest Group (OIG)
in the United Kingdom (U.K.). Specifically, I would like to get a point
of contact (e.g., name, postal address, phone number, e-mail address)
for each member of the group.

According to the March 1992 issue of "Hotline on Object-Oriented Technology"
the members of the group are:

	- Barckays Bank
	- British Airways
	- British Petroleum Research
	- British Aerospace
	- British Steel
	- British Telecom
	- Department of Trade and Industry
	- The Treasury
	- Ford Motor Company
	- Imperial Chemical Industries
	- Lloyds Bank
	- National Westminster Bank
	- Prudential Assurance
	- Rolls Royce
	- Royal Insurance
	- Trustee Savings Bank
	- University of Strathclyde

Thank you for any time and consideration.

				-- Shelley


---------New Address---------New Phone Number---------New FAX Number--------
Shelley C. Peacock                              | Phone: (301) 417-9884
Berard Software Engineering, Inc.               | FAX:   (301) 417-0021
101 Lake Forest Blvd., Suite 360                | E-Mail: scp@bse.com
Gaithersburg, Maryland 20877                    | 
---------New Address---------New Phone Number---------New FAX Number--------
Newsgroups: comp.object
From: mat@mole-end
Subject: Re: Object-oriented analysis (general query)
Organization: :
Date: Fri, 10 Apr 1992 22:42:38 GMT

In article <1992Apr10.002336.5995@projtech.uucp>, pryals@projtech.uucp (Phil Ryals) writes:
> In article <1992Apr3.180413.2731@colorado.edu> scotth@sigi.cs.colorado.edu (Scott Henninger) writes:
> >... the difference between object-oriented ... and structured analysis ...?
> 
> The major difference is that object-oriented analysis uses the information
> in the problem as the foundation for analysis, instead of the processing that
> structured analysis uses.
 
SA uses three primary models, and it doesn't have much room for stuff
that other models can discover.  OOA uses the `Object' model as a
primary model, but that model accomodates E/R and many other modelling
techniques.  (Look at Rumbaugh, at Booch, etc.)

OOA/OOD really do demand more of your recordkeeping and recordkeeping
tools; you have to be able to record a decision (either of interpretation
or implementation) and to find it quickly when something else brings you
up against it.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.object
Subject: Re: SUMMARY: Object-Oriented Software Maintenance (1200 lines)
Date: 15 Apr 92 11:52:39 GMT
	<BEVAN.92Apr8102029@panda.cs.man.ac.uk> <adwj5cb.objsys@netcom.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: objsys@netcom.com's message of 12 Apr 92 22:20:38 GMT

In article <adwj5cb.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
   In article <BEVAN.92Apr8102029@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
   >I suggest you try a more recent ML system, e.g. New Jersey ML
   >Most (all?) allow separate compilation as you can find in say C++, Ada
   >... etc.

   Great.  Do you know the implementation mechanism used to support
   polymorphism?

There is a section on it somewhere in :-
"Compiling with Continuations" by Andrew W. Appel.
The simple solution to the problem is to use the old maxim
(paraphrase) "all problems are solvable with another level
indirection".  This is fine for developing code (at least for me), but
in production stuff I'd want the compiler to be much more agressive it
its optimisation.  If the compiler is stupid (most C and C++ compilers
:-), then I develop in separate files, but for maximum performance
`cat' all the files together and let the compiler grind away at the
whole thing.  There are a number of caveats that go along with this,
but the general method works ok.


   ... otherwise, they'd require the same implementation tricks we use
   in OO.

As I'm in a particularly pedantic mood, I'd just like to point out
that said tricks (and lots of other things :-) don't have their
origins in OO i.e. IMHO the above is putting the cart before the
horse.

I think if you investigate the murky details of various Algol 68
implementations (probably Alphard/CLU/Ada as well) you'll find various
ideas that are being reinvented today with the OO label stuck on them.
For example, look at the transput library in Algol 68 and compare it
to C++ streams.


Stephen J. Bevan				bevan@cs.man.ac.uk
Newsgroups: comp.object
From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: C++ critique in comp.lang.c++
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Wed, 8 Apr 1992 12:13:38 GMT

I have placed a critique of C++ in comp.lang.c++. This may be of interest
to those following OO in general.
-- 
Ian Joyner                                     ACSNet: ian@syacus.acus.oz
ACUS (Australian Centre for Unisys Software)   Internet: ian@syacus.acus.oz.au
Tel 61-2-390 1328      Fax 61-2-390 1391       UUCP: ...uunet!munnari!syacus.oz
Newsgroups: comp.object
From: wagnermi@Informatik.TU-Muenchen.DE (Michael Wagner)
Subject: Re: C++ binding vs. Obj-C binding
Keywords: OOP, C++, Obj-C
Organization: Technische Universitaet Muenchen, Germany
Date: Thu, 16 Apr 1992 12:28:59 GMT

In article <2kyj45-.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
...
>P.S.  After hearing about the Objective-C extensions to C++, I've just
>  taken a look at GNU gcc 2.0 and found it provides either C, C++, or
>  Objective-C, but I don't see the Objective-C extensions to C++ anywhere,
>  am I missing something?

NeXTStep includes a schizophrenic compiler which can't tell if its C++ or
Objective-C.

8-)
	Mike

Newsgroups: comp.object
From: jjones@cs.uiuc.edu (Joel Jones)
Subject: REQUEST: Examples of Booch Class Category Diagrams
Reply-To: jjones@uiuc.edu
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 10 Apr 1992 16:55:57 GMT

I am doing some reverse engineering of a project using the notation described
in "Object Oriented Design with Applications" by Grady Booch and would like 
some examples of how people use class category diagrams.
-- 
Joel Jones      As the advertisment for an exhibition on Leonardo da Vinci said,
jjones@uiuc.edu "They called him a genius, a botanist, a demon, a philosopher, a
                 practical joker, an eccentric, and a visionary.  No wonder he 
                 was such a great engineer."
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: SUMMARY: Object-Oriented Software Maintenance (1200 lines)
Date: Mon, 13 Apr 92 01:11:47 GMT
Organization: Object Systems

In article <vcwjg0=.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
>P.S.  Personally, I assumed the expression "typeless" was coined at time
>      when static typing was the rule and dynamic typing the exception. So
>      when an important new language was introduced without static typing
>      (Smalltalk), it was metaphorically labeled "typeless", meaning not
>      supporting types as most people understand and use them, instead of
>      using a more descriptive and technically correct denotation such as
>      "dynamically typed".

P.P.S.
  Also, Smalltalk object declarations do not specify type or class, one
  must look at the initialization of an object to determine its type and
  parameters give no clue except for comments and the semantic content of
  their name.  Hence a quick look shows all objects to be the same as the
  epitomal void* type in C++ and objects can even change their class with
  the "become" Object method.  So this leaves Smalltalk as dynamically
  typed, but in the most unrestricted way because there are no type
  declarations at all!  This should not be confused with "typeless" as
  no types (assembly language) or weakly typed (holes in the type system).
[On Weakly Typed vs. Dynamically Typed, a subjective issue?]
  "Strongly typed" is well defined by ASU, but weakly typed isn't.  I
  prefer to distinguish between a type error not being distinguishable at
  all verses a type error being distinguishable at run-time.  After passing
  a strongly typed compiler, there can theoretically be no type errors, but
  then how can you distinguish between the remaining two cases with the
  historical definitions?  While I may have referred to weakly typed in the
  former case while others in the latter, perhaps this shows a problem with
  the definition in the first place.  Historically, weak typing covered
  both cases, since almost all production compilers and compilers texts
  used static typing exclusively, but no more.

  Consistent terminology is required, so perhaps some playing with the
  terms could help to make things even more confusing, maybe by adding
  static and dynamic to the term:-)
    weak static typing		strong static typing
    weak dynamic typing		strong dynamic typing
  So then weak and strong typing would have to be redefined, for example:
  a program is said to be "strongly statically typed" if a compiler can
  guarantee it contains no type errors at compile-time and a program is
  said to be is "strongly dynamically typed" if a (meta-level) compiler
  can guarantee it will contain no type errors at run-time.  Programs
  requiring dynamic typing could then be referred to as weakly statically
  typed but (preferred) strongly dynamically typed, thus filling the void.
  Notice the level of granularity is the program, since in dynamically
  typed languages it is still possible to write strongly statically typed
  programs.

bob
objsys@netcom.com
Xref: sparky comp.object:1726 comp.lang.objective-c:252
From: ede978e@monu6.cc.monash.edu.au (Robert D. Nicholson)
Newsgroups: comp.object,comp.lang.objective-c
Subject: Graphical user interfaces with OOP
Summary: Wanted: GUI with OOP articles
Keywords: OOP GUI MVC NextStep
Date: 10 Apr 92 06:40:04 GMT
Organization: Monash University, Caulfield Campus

I am currently researching my minor thesis which deals with this topic.
I am interested in any articles/theses that discuss this topic.

Articles or References to articles would be nice, preferably articles.

Thank you.
Newsgroups: comp.object
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: SUMMARY: complexity in O-O
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 10 Apr 1992 03:35:27 GMT

kalakota@ccwf.cc.utexas.edu writes:

>What is Software Complexity?

>Software Complexity is difficulty to maintain, change and understand programs.
>It deals with the psychological complexity of programs.

>What are best known complexity measures?

>Some of the best known complexity measures are Measure of McCabe (Cyclomatic number), Lines of Code (LOC) and the Measures of Halstead (Length, Volume, Difficulty and Effort).


This is a very interesting posting because of the juxtoposition of
these two questions.  Suppose you wanted to measure how difficult
it is to maintain, change, and understand programs.  What kind of
measure would you use?  Wouldn't you measure how long it took to
enhance and change a program, and how long it took before people
could accurately answer questions about it?  It seems to me that the
ONLY good complexity measures are those measure PEOPLE working with
PROGRAMS, not those that measure some syntactic aspect of the program.
In other words, the "best known" complexity measures are all junk.
They are worthless garbage, they are useless trivia, they are a waste
of time.  We should not be interested in syntactic measures of a
program unless someone has shown that it has a strong correlation
to maintainability, changeability, and ease of understanding.

This seems to me to be as simple as 2+2=4.  It is obviously true.

Further, nobody (to my knowledge) has shown that any of the "best known"
complexity measures have a strong correlation to the REAL complexity
measures.  So, why do people keep talking about them?  Is this all
a communist plot to keep us from solving more important problems?
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.object
Subject: Re: SUMMARY: Object-Oriented Software Maintenance (1200 lines)
Date: 8 Apr 92 09:20:29 GMT
	<BEVAN.92Apr3165546@panda.cs.man.ac.uk> <sqpjtsf.objsys@netcom.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: objsys@netcom.com's message of 7 Apr 92 04:31:59 GMT

In article <sqpjtsf.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
   In article <BEVAN.92Apr3165546@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
   >In article <3rkjx-q.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
   >
   >   ML is statically typed, so if I'm not mistaken, kiss
   >   separate compilation goodby, they check everything.
   >
   >Why should static typing mean you can't have separate compilation?

   Since ML supports polymorphism and claims to be statically typed
   and since the versions of ML I used were interpreted (nothing
   separate), I assumed all code would be available allowing all
   functions to be checked with calls to insure type correctness.

I suggest you try a more recent ML system, e.g. New Jersey ML
Most (all?) allow separate compilation as you can find in say C++, Ada
... etc.


   Does ML and/or Haskell place restrictions on polymorphic parameters,

Not in the sense of restricting the values to certain simple types,
no.


   Without separate compilation, I'm not sure if any dynamics [dynamic
   binding] are required at all. 

I hope I didn't cut away too much context here, as I read the above as
"dynamic binding isn't necessary if you compile all the files together
in one go".  Now I realise that you can compile away _some_ dynamic
calls if enough context information is available, but all?

bevan
Newsgroups: comp.object