HDTenEightyP/NetNews huggingface dataset:
From: sm86+@andrew.cmu.edu (Stefan Monnier)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 5 Sep 92 22:28:20 GMT
Article-I.D.: andrew.IeeOI4S00awBQURnxd
	<PFKEB.92Sep5213354@kaon.SLAC.Stanford.EDU>
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.object: 6-Sep-92 Re: Object-Oriented
Methodo.. Paul Kunz@kaon.SLAC.Stan (1246)

> In article <715276480.1.p00058@mail.psi.net> p00058@mail.psi.net (Ronald
> C. Schultz) writes:

> This post started a lot of discussion, but nobody seemed to notice
> what I consider a much more fundamental mistake...


>    ---- start of quote -------------------------
>    Class Description
>    Class Name: Circle
>    Version: 1.0
>    Description: Ellipse whose major and minor axes are equal
>    Super Classes: Ellipse
>    Features:
> 	   Public Attributes:
> 		   center: Point - location of its center
> 		   radius: Real - its radius
> 	   Public Methods: 
> 		   draw (Window) - draws a circle in the window
> 		   intersectLine (Line): Set of Points - finds the 
>    intersection of a line and a circle, returns set 0-2 points
> 		   area(): Real - calculates area of circle
> 		   perimeter(): Real - calculates circumference of circle
> 	   Private Methods: none
>    ---- end of quote --------------------------

> Nonsense.   A Circle is not a *subclass* of Ellipse, it is a *subset*
> of all possible Ellipses.   There's no need to define such a class.
> Confusion between subset and subclass is happening here.
> --
> Paul F. Kunz	pfkeb@slac.stanford.edu (NeXT mail ok)
> Stanford Linear Accelerator Center, Stanford University
> Voice: (415) 926-2884   (NeXT) Fax: (415) 926-3587

The problem is not to know if circle is a subclass of ellipse:

It is an ellipse! and inheritance can be interpreted as 'is a'
(of course, you can interpret it another way, but it is a way).

So you can define circle as a subclass of ellipse. This makes
sense when you want (for example) to write an intersection
method which can make use of the particularities of a circle 
(this method could more efficient (cause less general) than the
one for the ellipse).
Another example is for the perimeter !
A perimeter function for an ellipse is not really trivial. But
it is for a circle !

That's really useful !

In fact, it is the 'raison d'etre' (=~ the real usefulness) of
the inheritance: add specific behaviour and rewrite some 
methods (using particularities of the child to make it better)
without having to rewrite all and with the possibility to use
this new object as if it was of the superclass (I know: it is not
really clear!)

	Stefan Monnier

PS: I hope someone understood most part of it!
	sorry for that poor english ! 

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
From: graham@maths.su.oz.au (Graham Matthews)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: School of Mathematics and Statistics, University of Sydney
Date: Sat, 5 Sep 1992 07:52:23 GMT

(nicholas.hounsome) writes:
>here we have the problem - nobody has specified what they actualy mean
>by a circle!
>The purest form of circle you can define has only one property-its radius
>(or alternatively its diameter or circumference any of which is derivable
>from any other)
>
>A circle in itself does not even have position since there is no such 
>thing as a universal absoloute position.
>
>To progress from here you have no choice but to start making up families
>of objects so that you can define their relationships with each other.
>
>In particular the first thing that you have to do is define 
>CircleInMyCoordinateSpace derived from some ObjectInMyCoordinateSpace 
>which will be the base class for all geometric objects taht you wish to 
>deal with. Failing that you have no choice but to start introducing all 
>knowing lumps of code which understand the innards of geometric objects.
>
>This is the main problem facing object libraries - I can write a perfectly
>good circle class for 2d drawing but to make it realy useful I have to
>allow for it being used in 2,3 or even n-dimensional space.
>
>Smalltalk pushes the problem back a little but it doesn't realy solve much
>because most objects have so few properties that are entirely independent
>of their environment.

And this to me is the single biggest problem that OO will face in the
future. In my opinion OO is good in small problem domains where there
are only a small number of fairly static relations between objects.
Get into a domain like mathematics where every object is related to
every other object in many many ways, and OO begins to show its failures.
Class lattices get clumsy, many properties are not known or knowable
until run-time, etc etc.

graham
--
Graham Matthews                 And it's true we are immune
Pure Math, Uni.Sydney, Oz       When fact is fiction and T.V. is reality
graham@maths.su.oz.au
From: liao@siemens.com. (Wen-Pao Liao)
Newsgroups: comp.object
Subject: Object Store (OODB) ?
Summary: Asking Object store experience ?
Keywords: OODB
Date: 11 Sep 92 21:04:13 GMT

Does anyone in this group have OBJECT STORE (OODB)?
Can you tell us your experience of OBJECT STORE?
Thanks!!
From: rjp@dcs.ed.ac.uk (Rob Pooley)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 7 Sep 92 13:17:23 GMT
Organization: Edinburgh University

In article <1992Sep2.140048.11829@bcrka451.bnr.ca>, sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
> 
> It is possible that "the context of its use" is that it be generally
> useful.  It is not intended for one application only.  It is a utilitarian
> foundation class, application independent.  Such classes are necessary,
> obviously.  It makes sense to separate the application-specific needs from
> the generic building blocks.  
> 
> Your argument appears to preclude designing classes for re-use.  Or have I 
> misunderstood your comments?
> 

That's a bit more extreme than I intended. My experience seems to show that it
is rarely useful to design at too abstract a level. This may in fact make it
harder to re-use the class.

What I was trying to say was that there are probably limits to re-use and that
it is better to be clear about the context in which you intend such re-use to
take place. Geometrical shapes are a particularly slippery concept to deal
with, since they can be intended for several different purposes and so
understood in different ways.

Inheritance is not "Platonic", i.e. you don't start from a pure definition and
add compromises in terms of the world you use the concept in, do you? If not
then that means of re-use is inherently rooted in the context of its intended
end use.

Re-use in composition may be a better candidate for a pure view of classes,
but then the use of the objects derived from a class are defined in the
aggregating class and the object itself merely carries enough information to
define itself. Thus a circle is a tuple of radius and (possibly but not
necessarily) a centre.

Rob Pooley,

Fading into the shades of imperfection
Newsgroups: comp.object
From: KOCHER@141.58.123.1 (HARTMUT KOCHER)
Subject: Booch notation in PC CASE tools
Organization: University of Stuttgart, IND
Date: Mon, 7 Sep 1992 07:56:51 GMT
X-News-Reader: VMS NEWS 1.20

In the product news section of the latest "C++ Report" I found 
two PC-based CASE tools that support the Booch notation. 
The first company mentioned is Popkin Software and Systems 
Inc. and their product is called "System Architect". The second 
product is "Object System/Designer" from Palladio Software.
Can someone provide the addresses, fax numbers, or email 
addresses of the companies?
Has anyone any experience with those products he'd like to 
share or can someone provide more information? Which one 
would you prefer?

I'd appreciate any help.

Hartmut Kocher
Kocher@nvdv.e-technik.uni-stuttgart.dbp.de
From: st1lv@rosie.uh.edu (McLeod, Stephen)
Newsgroups: comp.object
Subject: Why is garbage collecting considered intregral to OOPS?
Date: 15 Sep 92 15:25:00 GMT
Organization: University of Houston
News-Software: VAX/VMS VNEWS 1.41

Hi.  I'm boning up on OOPS right now and the book I'm using said that without
automatic garbage collection, it is not OOP/OOD.  Why is this the case?  The
book is rather unclear on this particular point.
---
Stephen McLeod         6 days til next chemo session.  bleh
The Eternal? Student
From: James_-_Odell@cup.portal.com
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: Sun,  6 Sep 92 14:10:32 PDT
Organization: The Portal System (TM)
  <PFKEB.92Sep5213354@kaon.SLAC.Stanford.EDU>
  <1992Sep6.112634.9430@neptune.inf.ethz.ch>


>A Circle is not a *subclass* of Ellipse, it is a *subset*
>of all possible Ellipses.   There's no need to define such a class.
>Confusion between subset and subclass is happening here.

As I recall my mathematics, set and class are equivalent--at least 
according to Quine.  (Although for Bertrand Russell, the difference is 
that a set can be an object and a class cannot.)  
    In OO programming, a class implements a structure whose 
extension is a set.  Additionally, in classical OO programming 
(whatever that is) a set cannot exist without a corresponding class.  
In other words, whenever you have a set, you have a class; and 
whenever you have a class, you have a set.  Therefore, having a 
subset would *seem* to imply having a corresponding subclass.  
However, this is not *necessarily* true.  While having a subset 
implies having a corresponding class, a subclass is not *required*.  
A programmer may choose to implement the Circle subset with an 
Ellipse class.  Instances of circles would then be indicated with an 
instance variable or some other mechanism--instead of a Circle 
subclass.

   Does this make sense, or am I way off base?


jim


------------------------------------------------------------------------
James Odell                                     Ann Arbor, MI  USA
(313) 994-0833                             71051.1733@compuserve.com
------------------------------------------------------------------------
From: chonoles@sde.mdso.vf.ge.com (Chonoles Michael Jesse)
Newsgroups: comp.object
Subject: Re: OO Analysis & Design Tool Review
Keywords: OMTool
Date: 14 Sep 92 21:45:29 GMT
Organization: GE M&DSO - VF


As Steve Mellor will probably point out, there are several other tools that support OOA/D.

I would recommend GE's OMTool. It supports The OMT methodology and notation and currently
runs on several UNIX platforms.  It can be used to generate C++ and/or relational database
SQL. It also supports Interleaf for documentation purposes.


-- 
Michael Jesse Chonoles		Chief Technologist	chonoles@acc.vf.ge.com
GE Advanced Concepts Center	P.O. Box 1561 		Compuserve 71556,605
King of Prussia, PA 19406	United States		GEnie m.chonoles
1-800 GE TRAIN			TEL: 215 / 992-6212	Prodigy BFNB08A
From: James_-_Odell@cup.portal.com
Newsgroups: comp.object
Subject: Re: DFDs come naturally
Date: Sat,  5 Sep 92 19:27:41 PDT
Organization: The Portal System (TM)

ok
|I have some background in OO techniques. However, every time I 
start quit
|to analyze a system via diagrams, I naturally (i.e. not-consciously) quit
|start to draw a data-flow diagram.

|I don't necessarily say to myself... "Today, I'm going to use
|structured analysis". It just comes out that way.

|Has anyone else experienced this?

|To those of you who use OOA; does your OOA method come naturally
|or do you consciously apply it?


For me, DFDs have served as a way for organizing my thoughts.  
However, 
IMHO, I think they have to be modified to be used in an OO manner.  
In addition, DFDs--as they are classically defined--are not adequate 
for
methods specification.  That s why CASE tools can t generate 
executable code
from them.  In order generate executable  IF...THEN...ELSE-code the 
notation needs to be  strengthened .  Conventionally when a 
Process_A 
flows to a Process_B in a DFD it means that Process_A *precedes* 
Process_B.  If the meaning of the dataflow line could be changed 
from one 
of precedence to causality, an effective execution-directed notation 
could 
be defined.  Here, the dataflow line would actually become a trigger, 
so that the 
completion of Process_A *triggers* Process_B.  If Process_A, 
Process_B 
were defined to be OO operations with signatures and a class 
assignment 
(or class assignment*s* for you CLOS fans), the diagram would be a 
true OO 
method specification--in an OO analysis sense.  If this technique were 
adopted, the notion of data store would probably no longer be useful.  

I ve been useing this general idea for several years on several 
projects.  If 
you re interested, I can say more upon request.


Jim


------------------------------------------------------------------------
------
James Odell                                     Ann Arbor, MI  USA
(313) 994-0833                             71051.1733@compuserve.com
------------------------------------------------------------------------
------
Newsgroups: comp.object
From: graham@maths.su.oz.au (Graham Matthews)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: School of Mathematics and Statistics, University of Sydney
Date: Fri, 11 Sep 1992 00:38:41 GMT

Graham:
>To treat a field as a group however I must
>be able to to throw away an element of my carrier set. Above you
>describe which operations parameterise a group and a field, but you
>make no mention of the carrier set. How does the inheritance system
>know for example which element of the carrier set it must remove to
>view a field as a group?

(Philip Santas) writes:
>You do not need to remove anything: Subclasing here is supposed
>to _inherit_ code and not to remove. The above Field,
>inherits operations and axioms from two Groups and it may add some
>more axioms.

I am not talking about code, I am talking about carrier sets. The field
viewed as a group has to have a different carrier set. How do I specify
which is the zero element (as this is the one I want to remove).

Graham:
>>Say I want to say that all rings
>>are closed and finite (just assume they are). Now do I have to make
>>some class heirarchy like closed_ring < finite_ring < ring, or perhaps
>>I should make finite_ring < closed_ring < ring? Whichever I chose
>>there is an implied order in the class heirarchy that is not in the
>>mathematics.
>Normal _multiple_ subclassing is again enough:
>                   FiniteSet :< Set
>                      Ring :< Set
>   FiniteRing :< FiniteSet  /\   FiniteRing :< Ring
>There is _no_ order in the hierarchy here concerning the class
>FiniteRing.

Of course there is an order. You have

	FiniteRing < Ring < Set

FiniteRing expresses the finite property.
Ring expresses the closed property.

Why did you not make the heirarchy

	Ring < FiniteSet < Set

ie: why did you chose to subclass based on closedness before subclassing
based on finiteness?

graham
--
Graham Matthews                 And it's true we are immune
Pure Math, Uni.Sydney, Oz       When fact is fiction and T.V. is reality
graham@maths.su.oz.au
Newsgroups: comp.object
From: santas@inf.ethz.ch (Philip Santas)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Wed, 9 Sep 1992 13:23:19 GMT


In article <graham.716002888@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>santas@inf.ethz.ch (Philip Santas) writes:
>>
>>In this example, normal inheritance _can_ do the work.
>>Field(+,*) inherits from two classes Group (Group(+) and Group(*))
>>the operations + and * (multiple inheritance).
>
>Lets see how far this can be pushed...

We have pushed it very far!

>You have to do more than this I think Phillip as you also have to
>get a new element for your carrier set. A field is a multiplicative
>group with addition and a zero element (I think I have this the
>right way round). So you have to pick up a zero somewhere in your
>carrier set.

My above solution was just a hint. Of course I do have more parameters:

Field((+,0),(*,1)) :< Group(+,0) /\ Field((+,0),(*,1)) :< Group(*,1)

or more general:

Field((op1,Zero),(op2,One)) :< Group(op1,Zero) /\ 
Field((op1,Zero),(op2,One)) :< Group(op2,One)

or

Field((op1,Zero),(op2,One)) :< (Group(op1,Zero) + Group(op2,One))

As you see we do not have just one class Ring or Group, but many of them.
The above are functors which construct these classes.

You can say describe them as parameterised classes, but they are
actually functions which return classes.

>What about the example of a module and a ring. A module has two
>carrier sets, a ring one. But a module is a ring in some sense.

Again you use parameterised classes, and the resulting class
has _no_ carriers and it is a subclass of Ring given the operations 
you define.

Really, here _normal_ multiple subclassing does a pretty good job.

The problem arises when we have instances of these classes,
ie. Reals, Rationals, Integers. Normal subclassing as it is understood
in traditional OOP, is _very_ poor indeed.

The system we build (k-bench) deals with many of the questions you have
sent, inluding the subclasses of relationships. We hope to make it
available within the next few months.

Philip Santas

  "In an evolving universe those who stand still are really moving backwards"
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch				 Philip Santas
Mail: Dept. Informatik				Department of Computer Science
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41-1-2547391
Newsgroups: comp.object
From: vadim@cix.compulink.co.uk (Vadim Lebedev)
Subject: Re: O.M(...) vs M(...), and is
Reply-To: vadim@cix.compulink.co.uk
Date: Sat, 5 Sep 1992 09:04:00 +0000


In article <45jnpm_.objsys@netcom.com>
 objsys@netcom.com (Bob Hathaway) writes :

  [text dleted]

> >constraints instead of one simply invoking the other.
> 
> Actually, I was contending the real world contains real objects with
> attributes and properties (is object-oriented) and based an argument that
> some kind of object-oriented A/D/P/etc. is therefore the best candidate
> for real-world modeling right now.
> 
> >For example, computer objects do not abide by constraint relationships
> >such as like Newton's law; for every action there's an equal and
> >opposite reaction.
> 
> Including physical laws calls for a simulation with some kind of physical-
> world model.  Such a model can be elegantly designed with an object-oriented
> model and I have presented at least one trivial way.  This means the
> object-oriented constructs are simply used to simulate and model the
> real-world.  For example, the "world" will enforce an equal and opposite
> reaction whenever an object undergoes some force in the world model.  The
> simulation tracks such things and is programmed that way.  An interesting
> alternative is to develop special-purpose languages with physical dynamics
> built-in.  Do you have an opinion on this approach?
> 
> bob
> objsys@netcom.com
>

I strongly suspect that usuall OO approach will no leed too far on 
such a task unless augmented with concept of 'field'.
The fields are created by objects and  are 'felt' by them. 
A field modifyes certains aspects of object behaviour...


Vadim.


Newsgroups: comp.object
From: graham@maths.su.oz.au (Graham Matthews)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: School of Mathematics and Statistics, University of Sydney
Date: Wed, 9 Sep 1992 01:41:28 GMT

graham@maths.su.oz.au (Graham Matthews) writes:
>>No, all you seem to have considered here is the "is-a" relation.
>>Are there no other relations between objects? What about dealing with
>>the case where A is-a B in more than one way (eg: a field is a group
>>in at least two ways). This latter example suggests for example that
>>you need a more general way of specifying inheritance than just A
>>is-a B, something like A is a B under these conditions, is a B under
>>some other conditions ... This is all to do with relations between
>>types.

santas@inf.ethz.ch (Philip Santas) writes:
>In this example, normal inheritance _can_ do the work.
>Field(+,*) inherits from two classes Group (Group(+) and Group(*))
>the operations + and * (multiple inheritance).

Lets see how far this can be pushed...
You have to do more than this I think Phillip as you also have to
get a new element for your carrier set. A field is a multiplicative
group with addition and a zero element (I think I have this the
right way round). So you have to pick up a zero somewhere in your
carrier set.

What about the example of a module and a ring. A module has two
carrier sets, a ring one. But a module is a ring in some sense.

graham
--
Graham Matthews                 And it's true we are immune
Pure Math, Uni.Sydney, Oz       When fact is fiction and T.V. is reality
graham@maths.su.oz.au
Newsgroups: comp.object,comp.ai
From: terry@zoe.network23.com (Terry)
Subject: Need help with representing contextual relationships
Organization: Mystech Associates
Date: Tue, 8 Sep 1992 22:13:44 GMT

I am working on a project associated with modeling large complex
systems.  We currently are using an object-oriented representation
of the model.  Each object in the model has a set of attributes
where the value of an attribute can be a simple quantity or it
can be another modeling object, it can also be multivalued.
When the value is another object, the attribute is actually
representing a relationship between the objects.  The problem
with this approach is that it does not adequately address multiple
contextual relationships, i.e. the relationship is valid within a
particular context or the value may vary for different contexts.

If anyone has had any experience with this or knows of any useful
references I would appreciate it if you would e-mail me the
information.

Thank you.

Terry Raymond
-- 
terry@zoe.network23.com
{rayssd,xanth,mirror,att}!galaxia!zoe!terry
Newsgroups: comp.object
From: steve@projtech.com (Steve Mellor)
Subject: OO Analysis & Design Tool Review
Organization: Project Technology, Inc., Berkeley, CA
Date: Thu, 10 Sep 1992 19:21:09 GMT

A topic that was conspicuously missing from Kevin Hartig's posting
on OOA/D tool selection was the selection of the method.

It is *extremely important* that the selection of the method drive the
selection of the tool, and not the other way around.

What analysis/design method is this government project using?  Was it 
selected after tool selection?  

How about other tools supporting OOA/D?  Why just these three?
Just curious....
-------------------------------------
Steve Mellor      	steve@projtech.com
Project Technology	Training and Consulting using Shlaer-Mellor OOA/RD
Berkeley, CA		Tel: (510) 845 1484
--------------------------------------