HDTenEightyP/NetNews huggingface dataset:
From: steve@crc.ricoh.COM (Stephen R. Savitzky)
Newsgroups: comp.object
Subject: Re: Three approaches to designing OBJECTs
Date: 22 Jan 93 19:06:28 GMT
Followup-To: comp.object
Organization: RICOH California Research Center

I recommend a variation on your approach 1.

Give Entity a virtual function (I usually call it dscr()) that returns
a descriptor for the entity, having as one of its attributes a list of
attribute-name / attribute-descriptor pairs.  If you're really lucky,
you can get this information out of the OODB's schema.  Otherwise, you
could be ambitious and get them by parsing the declarations yourself.

Note that the descriptors are not persistent -- they're just static
data structures referred to by the dscr() function.  Because they're
not stored with the object, they can have application-specific stuff
in them, like how to display the attribute and where it goes on a
panel.

You can do a lot with a descriptor of this sort, including the generic
Get, Set, and display stuff you mention, and also generic stream I/O
(<< and >> operators).  Put a class name in the Entity descriptor, and
you can use it in error messages.  You can also do run-time class
checking.
--
\ --Steve Savitzky--  \    343 Leigh Ave   \ REAL HACKERS USE AN AXE!
 \ steve@crc.ricoh.COM \ San Jose, CA 95128 \     Free Cyberia!
  \ w: 415-496-5710     \   h:408-294-6492   \ 
   \_________________________________________________________________________
Xref: sparky comp.object:5014 comp.software-eng:5419
From: grp@dmu.ac.uk (Graham Perkins)
Newsgroups: comp.object,comp.software-eng
Subject: Re: Why and how do organizations select O-O approach to S.E.
Date: 22 Jan 93 13:57:28 GMT
Organization: De Montfort University, Leicester, UK.



>I have been going though the software engineering literature (primarily
>OO literature) to understand and enumerate the reasons why organizations,
>firms or groups have chosen or were seriously thinking about using 
>an object oriented approach to software engineering. There is an amazing
>lack of objective, evaluative literature on the selection of methodologies
>in software engineering. We seem to be carried away by the bandwagon effect

ANECDOTAL EVIDENCE:
==================
My brother heads up a contract software team at a big bank in the City
(of London, that is).  He recently put together a proposal for a new
software project to meet some requirements expressed by management and
customers.  Basically, they needed a new version, fully integrated with
MS-windows, and a bit more functionality, to replace their existing
system of financial information retrieval.  Basically, they want v.smart
spreadsheet/dbase interaction on their screens, but database itself
is remote & different OpSys etc.
The chief programmer employed on bro's software team insisted the
product had to be coded in C++, because it was "Object oriented, and
object oriented languages are all about message passing, which is
what we want".   
Alas, this policy was pursued for a couple of months before my
brother discovered that it was balderdash and that the aforementioned
programmer had more hot air than ability.  Much time and money
was wasted.
Newsgroups: comp.object
From: davis@passy.ilog.fr (Harley Davis)
Newsgroups: comp.object
Subject: Re: FAQ  Part 1 (of 2) [ objects, closures, continuations ]
Date: 22 Jan 93 09:52:34 GMT
	<1993Jan15.033713.27130@netcom.com> <PCG.93Jan19235921@decb.aber.ac.uk>
Organization: ILOG S.A., Gentilly, France
In-reply-to: pcg@aber.ac.uk's message of 19 Jan 93 23:59:21 GMT


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

   (Bob Hathaway) said:

   pcg> More precisely objects are values of a procedure instance
   pcg> (closure/continuation) record type.

   objsys> Since the FAQ will typically be for newcomers, could you please
   objsys> put the last sentence in English and/or give references?

   The references are easily produced: "Hierarchical Program Structures",
   in "Structured Programming", Academic Press, and "Structure and
   Interpretation of Computer Programs", MIT Press.

   In particular they show that (in class based OO languages) classes are
   procedures, and objects are procedure instances; closures if the
   language is a traditional OO one, and continuations if the language is
   an actor OO one.

Classes and objects are not procedures; rather, they can be
implemented or, perhaps, thought of as procedures in some languages
for some OO models.  Two reasons:

1. In latently typed languages with first-class procedures, most
   objects (except for real procedures) will return false when asked
   if their type is procedure.

2. The simplistic SICP OO implementation in terms of closures does not
   account for multi-methods.

Also, what is the difference between a "procedure" and a "procedure
instance"?  Perhaps you meant to say that a class can be thought of as
a procedure which returns procedures.

-- Harley Davis
--

------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France
Newsgroups: comp.object
From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Active Objects - What is the Problem?
Organization: AT&T
Date: Thu, 21 Jan 1993 09:59:17 GMT

I have been trying to follow the thread on active objects and
have become completely lost. Unfortunately most of the contributors
seem to be lost too since everyone seems to be arguing over definitions.

In the heat of the discussion the point of the discussion seems to
have been lost. Perhaps the best way to approach this is for people
to say exactly what they think their active objects are needed for
and then we can all judge what they mean by looking at their examples.

In my case I have an object which has to communicate accross a WAN.
If I wrote it in C++ say and I had a method 'flashLed' which flashed
a LED on some remote system then the process would block for an 
unacceptable period of time when it could be doing other things.
If I use asynchronous communication and return from my method before
an acknowledgement is received then I cannot regain the context
in which the acknowledgement should be received.

It seemed to me that some of what I want could be achieved by implementing
objects as instances of SDL processes. The only problems with this
from my point of view is that it would be impractical to implement
the more traditional simple objects such as sets, complex numbers
and strings in this way - Although I consider this to be bad on 
general philosophical and theoretical grounds it would do for me if it
wasn't that I have an aditional requirement for persistence .

The long term goal of OOP as I see it is to have objects that are
just like real world objects such as people - They can act autonomously,
concurrently and either do several things at once or at least receive
a message and note it for future action whilst processing another.
Also they are persistent.

Nick Hounsome
AT&T Network Systems UK Ltd
Newsgroups: comp.object
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: FAQ  Part 1 (of 2) [ a bit of polemic ]
Date: 25 Jan 93 21:32:31 GMT
	<PCG.93Jan19231409@decb.aber.ac.uk> <1993Jan21.024452.6085@netcom.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

>>> On 21 Jan 93 02:44:52 GMT, objsys@netcom.com (Bob Hathaway) said:

Hathaway> "Simply put, an object is a variable"

Hathaway> Actually, I changed the above to "instance" instead of
Hathaway> "variable" and all should be well.

On this I would like to speculate. Your original text contained too many
times the word "variable" out of place to make me think it was just a
typo. Many times I have had the impression that your rather terrible
terminology covers a fairly intuitive (but not very deep) understanding
of this field.

In the particular case my impression is that you meant 'an object is a
variable' as a deformation of the concept, that indeed appears in the
literature, that an object is a *mutable* value/data structure, which is
quite a different thing, but one that it is rather likely you might have
been confused by.

The "OO programming is discrete simulation" school of thoughts maintains
that objects represent the state, associated with state access/change
functions, of "real world" entities. In other words, that an object is
the state vector of a (finite) state machine (the state machine
definition is the class -- in programming terms this translates to the
procedure/procedures instance view of classes/objects).

According to this view, an object is inherently mutable, and has been
described as such in the literature, because an immutable state vector
is quite inconceivable in a simulation context.

So I speculate that this might have been what you had in mind when you
wrote the above definition.

(let me register that even if I think that the definition of object as a
"mutable data structure" is defensible on the grounds above, and can be
found in the literature, I do not like it; the view that objects are the
state vector of some state machine, precisely because this makes the
notion of "frozen" state, i.e. a constant/immutable object, rather
unnatural, when instead it is quite useful).

Hathaway> Also, I seem to recall you trying to give an example where a
Hathaway> hierarchical class structure was not necessary and failed
Hathaway> miserably

What I remember is being challenged to give examples where a
hierarchical class structure is not *sufficient* and me pointing out
that I need not to, as the limitations of hierarchical data
classification schemes have been well documented in database textbooks
for over a dozen years (the network and relational data models, and the
need to have non hierarchical data dictionaries too, have been around
for a dozen years).

Hathaway> Anyway, my main point was to ignore these superflous comments
Hathaway> and get on with things, not to heat them up, so no more.

This is against all netiquette as clearly illustrated by Emily Netnews.
--
Piercarlo Grandi <pcg@aber.ac.uk> c/o Dept of CS
University of Wales, Penglais, Aberystwyth SY23 3BZ, UK
Newsgroups: comp.object
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Non-Compatible Type Inheritance in Booch's Method?
Organization: Rational
Date: Fri, 22 Jan 1993 22:22:53 GMT

880445p@dragon.acadiau.ca (Ravi Palepu) writes:

|I just gave a seminar on the Booch methodolgy, and of course, someone
|asked a question that I hoped nobody would. (Lesson in humility)

|Could someone shed some light on inheritance relationships that are
|not type compatible? (Class Diagrams from 5.2 of OOD w Apps) 

|According to the book, he uses derived types in Ada as an example.
|Thanks in advance.

You can get a copy of Booch's latest paper on the Notation by mailing
a request to prod_info@rational.com

The notation now supports the inheritance arrow in public, private and
protected forms.

		-----------> public inheritance

		--|--------> protected inheritance

		--||-------> private inheritance

The old, "inherits (new type) relationship is now a private
inheritance relationship.  It indicates that the inheriting class does
not conform to the ISA relationship.  The public interface of the
base class is not visible to clients of the subclass.  Thus, the
subclass is a new type, rather than a type which is compatible with
the base class....

Although there are some good reasons for using private inheritance
from time to time, it is usually preferable to use private
containment.

--
Robert Martin       | Design Consulting    | Training courses offered:
R. C. M. Consulting | rmartin@rational.com |  Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004  |  Object Oriented Design
Green Oaks, Il 60048| Fax: (708) 918-1023  |  C++
From: C.D.Turner@newcastle.ac.uk (Chris Turner)
Newsgroups: comp.object
Subject: Re: Testing - Tech Report
Date: 21 Jan 93 17:17:01 GMT
Organization: University of Newcastle upon Tyne, UK, NE1 7RU
X-Newsreader: TIN [version 1.1 PL6]

Unfortunately quite a number of you (especially those across the
pond) seem to have a problem with an unknown host error when trying
to access vega.dur.ac.uk 

It's IP address is 129.234.4.28

if this still doesn't resolve the problem, does anyone have suggestions
where else I could put it (i.e. a ftp site across the waves) ? 

As I said in the earlier posting, I would really appreciate any
feedback anyone is able to give me.

Thanks

Chris Turner

Department of Computer Science, University of Durham, DH1 3LE England
Tel. +44 91 374 3657 FAX +44 374 3741 E-Mail C.D.Turner@durham.ac.uk
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Re: FAQ  Part 1 (of 2) [ a bit of polemic ]
Organization: Object Systems
Date: Sat, 23 Jan 1993 05:33:10 GMT

In article <KERS.93Jan21094141@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>This is not how I understood polymorphism was interpreted -- either in OO or
>more traditional CS. (It would, however, fit into D&D :-)

Please see my post on this; I believe I give sufficient quotes to update
Strachey's interpretation and show that he's the one really getting
away from the canonical definition, probably due to the standard
procedural/functional paradigm of his times.

bob
objsys@netcom.com
Newsgroups: comp.object
From: smccoy@dw3g.ess.harris.com (Scott McCoy)
Subject: HELP: POC for Purify
Followup-To: poster
Date: Sat, 23 Jan 1993 18:46:14 GMT
Organization: Harris Corporation Information Systems Division
Keywords: grabage collection, memory management

I need a U.S. point of contact for the tool Purify, 
which was mentioned some weeks back during the most 
recent round of garbage collection discussions.

E-mail only please:  smccoy@dw3g.ess.harris.com

-- 
Scott McCoy	Harris ISD	Opinions expressed are my own.
Staff Eng - SW	Internet: 	smccoy@dw3g.ess.harris.com
From: an5802@anon.penet.fi (The Inquisitive One)
Subject: Comparison of OODBs
Organization: Anonymous contact service
X-Anonymously-To: comp.object
Date: Sat, 23 Jan 1993 06:20:01 GMT


Does anyone know of any work on comparison of two or more OODBs for effiency, speed, etc ? Any sources would be welcome.
I do know of the existence of the OO1 benchmark developed at Wisconsin in March 1992.

Thanks 

P.S. Has there been any comparative study of the various OODBs in the market, in general, in terms of implementation and other features available to the programmer ?

-------------------------------------------------------------------------
To find out more about the anon service, send mail to help@anon.penet.fi.
Due to the double-blind system, any replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Xref: sparky comp.object:5012 comp.software-eng:5415
From: jaffeb@iccgcc.decnet.ab.com (BRUCE S. JAFFE (X4185))
Newsgroups: comp.object,comp.software-eng
Subject: Metrics For Object-Oriented Software
Date: 19 Jan 93 12:50:42 EST

I am looking for information on how to measure/estimate/predict software size
for an object-oriented system.  The intent is to use size as a time/effort
indicator that can be used for scheduling/tracking of project plans.  If you
are aware of any relevant sources, please email references to me at
bsjaffe@odin.icd.ab.com.  I will post a summary if appropriate.
Newsgroups: comp.object
From: silva@calypso.cs.wayne.edu (Joao Silva)
Subject: 2nd  Workshop on PROGRAM COMPREHENSION
Organization: Wayne State University, Detroit, MI
Date: Mon, 25 Jan 1993 16:02:02 GMT


                         CALL FOR PAPERS

                        2nd  Workshop on

                     PROGRAM COMPREHENSION

                        July 8 - 9, 1993

            Europa Palace Hotel, Capri, Naples, Italy

Most "real life" software engineering deals with existing 
software. Maintenance, reuse, and re-engineering are 
some of the most expensive processes. A significant part of 
their cost is due to software comprehension.
  
This workshop will explore the theoretical, 
methodological, technical, and technological issues of 
program comprehension. It will gather researchers from 
government, academia, and industry.

Papers related, but not limited, to the following topics are 
invited:

- Theories and models for software comprehension
- Experiments related to software comprehension
- Tools facilitating software comprehension
- Reverse engineering to support reuse,  comprehension,            
	    and maintenance
- Innovative technologies for reverse engineering
- Case studies in reverse engineering 
- User interfaces, program visualization and animation.
     
General Co-Chairs:

Bruno Fadini
Project SICP-CNR 
Viale del Policlinico, 137 - 00161 Roma

Vaclav Rajlich
Department of Computer Science
Wayne State University
Detroit, MI 48202
e-mail: rajlich@cs.wayne.edu

Sponsored by:


	The Institute of Electrical and Electronics
	Engineers, Inc.


	IEEE Computer Society

Program Co-Chairs:

Aniello Cimitile
DIS - Dep. of Informatica e Sistemistica
University of Naples
via Claudio 21, 80125 Naples, Italy
(Please use express mail)
Tel. ++39-81-768-3199
Fax ++39-81-768-3186
e-mail: cimitile@inacised.unina.it

Norman Wilde
Department of Computer Science
University of West Florida
Pensacola, FL 32514
Tel. 904-474-2548
Fax 904-474-3023
e-mail: wilde@cs.uwf.edu

Information for authors:

Papers due March 1, 1993
Acceptance notification April 10, 1993
Camera ready copy due May 10, 1993

Submit three (3) copies to the program co-chairs.
Papers should be original work of approximately 
6000 words.  They should not have been previously 
published nor have been submitted to, or be in 
consideration for, any journal, book, or conference. 
Authors are expected to present the accepted paper 
to the workshop.

In Cooperation with:

Project SICP-CNR, Italian National Research 	
Council

ALENIA, Naples

CRIAI - Consorzio Campano per la Ricerca in 	
Informatica ed  Automazione Indistriale


Informatica, Srl., Bari
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: How About Using Bootch for Analysis?
Organization: Rational
Date: Fri, 29 Jan 1993 00:39:08 GMT

khalsa@SanDiego.NCR.com (G.K. Khalsa) writes:

>The one other area where Booch's notation may be weak is in the
>ability to develop high level views of the model.  For large systems,
>it is not practical to represent a specification as a flat, huge
>set of classes/objects and their interactions.  Coad/Yourdon and 
>Embley, Kurtz and Woodfield are two texts that describe ways to
>present a model in manageable chunks.

I beg to differ.  Booch's notation has a very powerful method for
dividing a design into "chunks".  In fact, it is the richest
mechanisms I have seen to date.

Booch recommends that you break your design up into aggregates of
classes called "Class Categories".  The notation supports these
entities and relationships between them.  Class categories may be
related by "Visibility" which means that some of the classes in one
category make use of some of the classes in the other.  Booch's
notation also allows you to specify which classes are visible outside
a category and which are private to the category.  This is powerful
stuff.

--
Robert Martin       | Design Consulting    | Training courses offered:
R. C. M. Consulting | rmartin@rational.com |  Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004  |  Object Oriented Design
Green Oaks, Il 60048| Fax: (708) 918-1023  |  C++
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: Rethinking the Object Paradigm
Date: 22 Jan 93 15:45:31 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

>>> On 15 Jan 93 14:56:55 GMT, rapp@clear.com (Chuck Rapp) said:

Rapp> If all objects exist within a single process, an operation may be
Rapp> accessed via a routine call, i.e. pushing the arguments for the
Rapp> operation on a stack frame and jumping to the start of the
Rapp> operation's code. That is how C++ (my lingua franca) interprets a
Rapp> reference to an object's operation.

Rapp> But what if the objects are spread across multiple processes and
Rapp> multiple computers? Obviously the above technique simply won't
Rapp> work because there is no way for one process to access another
Rapp> process' stack or code.

Not so obvious... If one is clever this *is* possible. My long term
project (started ten years ago, and constantly sidetracked, but might be
finished in a year or so) is an OS kernel in which this is possible. The
technique is very easy: to make a thread jump from one machine to
another, just copy the (last relevant part of the) stack segment to the
machine where the operation's code resides (of course if the two address
spaces are on the same machine one just remaps the stack segment).

Rapp> The solution is for some sort of message passing between objects.

Not at all; one just makes threads jump from one address space to
another, as decribed above. Each address spaces contains one or more
"type managers" (a.k.a. classes, more or less).

Thread passing has also been "reinvented " by other people; for example
the Rochester people that did Elmwood and Psyche and the GeorgiaTech
people that did Clouds (even if they speak of making threads jump from
object to boejct, not class to class, which is rather odd; an
interesting set of papers is available by anonymous FTP from
"helios.cc.gatech.edu"); on a much more sophisticated scale it was the
central idea of Flex by the people at the Malvern RSRE.

If you want to get really farther back, the technology (albeit for the
non distributed case, but already in essence there) was first introduced
in the PDP-1.

My usual observation that most OO people, and not just Hathaway, are
unaware of things like capability architectures applies. Too bad for
them.
--
Piercarlo Grandi <pcg@aber.ac.uk> c/o Dept of CS
University of Wales, Penglais, Aberystwyth SY23 3BZ, UK
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.object
Subject: Re: FAQ  Part 1 (of 2) [ identity and OO paradigm ]
Date: 25 Jan 93 13:27:27 GMT
	<1993Jan22.004305.16275@netcom.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: objsys@netcom.com's message of 22 Jan 93 00:43:05 GMT

In article <1993Jan22.004305.16275@netcom.com> objsys@netcom.com (Bob Hathaway) writes:

   People think of objects as having structure and behavior (and more
   recursively, usually through inheritance) and this can be directly
   supported with a natural OO model.  Why contort this into a closure
   (or record with a function pointer and free variable list)?  It
   *may* be possible, but quite unnaturally.

A big IMHO is necessary there I think.  Some people contort
(unnecessarily pejorative term IMHO) objects in an attempt to see what
lies behind the hype that spews forth from many of is proponents.  In
this way, the real issues can be evaluated without getting bogged down
in the latest terminology.  As an example of this, try "First-Class
Extents" by Sinn-Der Lee and Daniel P Fiedman, Indiana Tech
report 1992.  This does not set out to discuss OO, but by
investigating a particular concept (extents), it creates a framework
in which _a_ particular model of OO can be recast.

bevan