HDTenEightyP/NetNews huggingface dataset:
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Re: Object-Oriented Methodologies - Class Specifications
Date: Sat, 05 Sep 92 02:26:21 GMT
Organization: Object Systems

In article <KERS.92Sep4092632@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>In article ... Bob Hathaway <objsys@netcom.com> writes:
>
>   P.S.  I still contend that dynamic functions are just functions and generic
>   functions aren't necessary for selection since they could be eliminated
>   from the language without a semantic difference.  The methods are all that
>   are *necessary*, no?
>
>No.

I think you're wrong again, Chris; it was really a rhetorical question, at
least in the general function case (I was wondering about CLOS idiosyncrasies
that I'm not aware of).  I'm not a CLOS programmer but it looks to me like
requiring the "virtual" keyword in C++; its not necessary and some have
argued can interfere with reuse - what if a "virtual" is forgotten in an
unchangeable library?  I was hoping a real CLOS programmer could provide some
insight since CLOS isn't my specialty but is quite interesting (and discussed).
It looks to me like generic functions were just added along with methods.
Anyway just to be more clear, I was obviously referring to CLOS generic
functions and methods and not to CL generic functions.

The (apparently) extra construct really surprises me since CLOS doesn't usually 
require extra constructs.  For example, CLOS doesn't require forward
declarations of classes and I believe even allows for their general use (at
least for parents).

bob
objsys@netcom.com

P.S.  Maybe I shouldn't pick on CLOS?  The designers seem quite eager for
  its next generation successor so I hope they don't mind.
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: Mon, 14 Sep 1992 00:12:02 GMT

(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.
(Graham Matthews) writes:
>>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).

(Philip Santas) writes:
>But you do have the ZERO element in the parameters of the parameterized 
>class Field((op1,ZERO),(op2,ONE)), and therefore you can do what you 
>wish with it in the body of the function (parameterized classes
>are functions).

No I do not necessarily have the zero in my parameterisation. You are
assuming that because I want to "deconstruct" my field by removing a
zero (to make it into a group) that I necessarily "constructed" my field
by giving the zero. That is not necessarily the case!

(Philip Santas) writes:
>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.
(Graham Matthews) writes:
>>Of course there is an order. You have
>>       FiniteRing < Ring < Set
>>FiniteRing expresses the finite property.
(Philip Santas) writes:
>This part is a result of my above scheme.
(Graham Matthews) writes:
>>Why did you not make the heirarchy
>>       Ring < FiniteSet < Set
(Philip Santas) writes:
>Because Rings are not necessarily Finite Sets.
>Rings are Sets (or you can say: Rings are Groups which
>are Monoids, which are SemiGroups, which are Sets;
>There is no place for FiniteSet in between)

Oh dear. You could make the following

		FiniteRing < FiniteSet < Set
		NonFiniteRing < NonFiniteSet < Set

But no you chose to make your previous heirarchy? Why? There is no
reason to make the heirarchy in the way you suggested, why not do
it the way I suggested? Also try adding in enumerability while you are
at it - doing so ably demonstrates the lack of order in the mathematical
properties, but the imposed order in the inheritance heirarchy.

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
Xref: sparky comp.object:3544 comp.lang.smalltalk:1818 comp.lang.eiffel:1139
From: verber@parc.xerox.com (Mark Verber)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: Future Issues of Object Orientation - ?Self?
Date: 14 Sep 92 22:26:33 GMT
Distribution: usa
Organization: Xerox PARC, Palo Alto, CA

Self is very different from SAIL and MainSail.  You can get papers
about Self (primarily from OOPSLA conferences) from the anonymous
ftp server self.stanford.edu:/papers.

--mark
Newsgroups: comp.object,comp.lang.c++
From: opdyke@ernie.cs.uiuc.edu ()
Subject: Re: Refactoring Object-Oriented Frameworks
Organization: University of Illinois, Dept. of Comp. Sci., Urbana,  IL
Date: Thu, 10 Sep 1992 21:00:32 GMT

In addition to the printed copies of my thesis available from
the University of Illinois, the thesis is also available (in
postscript format) via anonymous ftp.  Send me email if you
are interested in the details on how to retrieve it.

Bill Opdyke
opdyke@cs.uiuc.edu; opdyke@iexist.att.com

Newsgroups: comp.object
From: ewoods@hemel.bull.co.uk (Eoin Woods)
Subject: Re: Booch notation in PC CASE tools
Organization: Bull HN UK
Date: Mon, 7 Sep 92 12:07:44 GMT

KOCHER@141.58.123.1 (HARTMUT KOCHER) writes:
>The first company mentioned is Popkin Software and Systems 
>Inc. and their product is called "System Architect".
The UK distributor is:

	Real Techniques and Methods
	118 Warwick Street
	Royal Leamington Spa
	Warwickshire
	UK CV23 4QY
	+44-926-450858 (TEL)
	+44-926-422165 (FAX)

Eoin.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Eoin Woods                         | Tel : +44 442 88-4467 (Fax 4570)     |
| Application Services Product Unit  | BVN : (UK) 773-4467                  |
| Bull Information Systems           |                                      |
| Maxted Road                        | E.Woods@uk03.bull.co.uk              |
| Hemel Hempstead, Herts HP2 7DZ, UK | ...!relay1.uu.net!uknet!brno!ewoods  |
From: rge@quintro.uucp (Rob G. Erickson)
Newsgroups: comp.object
Subject: OS Wrappers
Keywords: OS wrappers, C++
Date: 12 Sep 92 20:56:09 GMT
Organization: Glenayre Electronics

I am currently working on an OO project can possibly change it's operating 
environment.  Trying to make this easier, I'm putting a C++ wrapper around
all system calls, to enhance portability.  What I was wondering is has anyone
out there already done this, and/or is there a library or a standard method
out there I can use to do this.  Anything to save work. 

                                    Rob Erickson
                                    Glenayre Electronics

-- 
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
Rob G. Erickson -Glenayre Inc., Quincy, IL- quintro!rge@lll-winken.llnl.gov
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: Thu, 10 Sep 1992 13:27:32 GMT


In article <1992Sep9.105320.9895@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
>
>[...] Inheritance

(I hope you mean _Subclassing_ here)

>has several legitimate uses, but it is only one relationship among
>many.  It is a relationship between classes, not objects, and
>that is an important distinction.

What happens in the case which classes are First Class Objects?

>a paper by Ken Rubin and Adele Goldberg on "Object Behavior Analysis".  
>One of the side comments that they made is that at one time they tried to
>enumerate all the different kinds of relationships that can exist
>between objects, and they eventually gave it up.  They decided that
>there are an infinite number of relationships between objects, and
>that it isn't possible to make a nice little table of them.  

This argument is a bogus: there can be also an infinite number of 
Classes or an infinite number of their instances: does that mean
that a system should not support classes?

What has been asked, was a system in which the definition of new
relationships were possible. Traditional OO sustems offer
just two _inflexible_ relationships: SubclassOf and InstanceOf.

I do not argue against providing these two relationships.
What has been said, is that, advanced systems should allow the user
to define his own relationships among classes whenever he wishes,
and without the need to redefine the whole kernel, or set of libraries.

>In summary, I see inheritance all over the place.  Just because
>inheritance doesn't handle every relationship (or even the majority
>of them) doesn't mean that it isn't useful.  

Nobody has argued against _subclassing_. But some people need
something more than this.

>Inheritance lets us
>define a relationship like Owner/Property once and reuse that
>relationship over and over again.  It also lets us reuse objects
>that we create to represent relationships, like the Purchase event object.

But this is what Functional Programming does without the need
of special form of Inheritance.

relat1 :: Owner->Property

What is so special with Inheritance after all? 

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: srm@matrix.com (Steve Morris)
Subject: where was this paper published?
Summary: page missing from LVM/OOD paper by K. Shumate
Date: Thu, 10 Sep 1992 18:33:40 GMT
Organization: Matrix Corporation


I have (most of) a copy of a paper titled...

        Layered Virtual Machine/Object-Oriented Design

by Ken Shumate (Hughes), which appeared in an ACM publication
in 1988. My local university library can't find it.

My copy is missing the 6th page. Does anyone know in
what journal or conf. proceeding this paper was published?

Thanks,

-- 
Steve Morris  ||  MATRIX Corp.  ||  919-231-8000 (8001 FAX) ||  srm@matrix.com
Newsgroups: comp.object
From: jgk@osc.COM (Joe Keane)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Summary: Multi-methods are confusing.
Keywords: signature
Date: 9 Sep 92 02:03:07 GMT
Reply-To: Joe Keane <jgk@osc.com>
Organization: Versant Object Technology, Menlo Park, CA
Weather: sunny, high 88, low 56
Moon-Phase: waxing gibbous (92% of full)

In article <1992Sep2.135247.11696@bcrka451.bnr.ca> sjm@bcrki65.bnr.ca (Stuart
MacMartin) writes:
>Yes, I suppose.  But intersectLine???  Do you really support having a
>pair-wise solution?  If I want to add another GeometricObject if there are,
>say, 10 already, do I add 10 intersection methods????  What about the 
>symmetric intersection methods in the other classes?  How do I then find
>the intersection of two arbitrary geometric objects?  Must I be able to
>find the types at runtime?

What's interesting about this is that it seems like *in general* you can't get
the implementation of a method to depend on the type of both objects.  This
sounds wrong, so let me explain what i mean.

Suppose that there are well-known classes A and B, and a method M which
operates on instances of both.  Initially there is an implementation for
M(A,B) and we want to see how people can override this implementation.  Now
suppose that person X makes a class AX which is a subclass of A.  Then he can
write a new implementation for the combination M(AX,B).  Similarly, person Y
makes a class BY which is a subclass of B, and also writes an implementation
for the combination M(A,BY).

So what happens when the method M is called with the combination M(AX,BY)?
There can't be a specific implementation for this combination, because no one
knows about both classes AX and BY.  (Of course we could generate code, but we
need some method for doing that, so this doesn't change anything.)  So we have
to pick one of the implementations M(A,B), M(AX,B), or M(A,BY).  It seems kind
of arbitrary.  And in any case, one or both of people X and Y is going to be
confused because his implementation didn't get run even though the arguments
seem to be of the correct type.

Now you say, we can get sort of the same thing by putting a whole bunch of
virtual methods on A and B, and having M(A,B) run them, maybe bouncing
information back and forth a couple times before it decides what to do.  In
this way we can get new *behavior* for M(AX,BY) which doesn't occur in either
of the cases M(AX,B) or M(A,BY).  I don't have any argument with that.  The
point is that the *implementation* must be one of the previous ones, so the
way in which the behavior is determine is somewhat fixed in advance.

--
Joe Keane, professional programmer
jgk@osc.com (uunet!amdcad!osc!jgk)
Xref: sparky comp.object:3526 comp.lang.c++:13574 comp.lang.eiffel:1137 comp.lang.smalltalk:1814
From: nicted@toz.buffalo.ny.us (Nicole Tedesco)
Newsgroups: comp.object,comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk
Subject: Re: Future Issues for Object Technology
Date: 13 Sep 92 15:31:19 GMT
Organization: The Tower of Zot - (716)691-3865

dvorak@ast.dsd.northrop.com (dvorak joseph l.) writes:
>  I would like to start a discussion about what people believe
>  will be the critical issues in object technology in the next
>  5 - 8 years. What solutions to these issues do you see and
>  how will the solutions affect the object model?
>  If you do not wish to or cannot post your answer, you can
>  mail it to me. I will post a summary of all mailed replies.

Near-future issues of Object Technology I see are:

1) Interoperability/Compatibility issues
2) APIs as Object Systems (i.e., Object Request Broker standard)
3) Perhaps parallel processing
4) The O-O and A.I. connection

- Nicole

---------------------------------------------------------------------
nicted@toz.buffalo.ny.us (Nicole Tedesco)
-- Change this!
Newsgroups: comp.object
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Wed, 9 Sep 1992 09:55:27 GMT

graham@maths.su.oz.au (Graham Matthews) writes:

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

For an example of how to handle this, see "A Smalltalk System for 
Algebraic Manipulation" in OOPSLA'86.  Note that, strictly speaking,
they had to extend Smalltalk to get the language features that they
wanted, though Smalltalk is flexible enough that they could do it
entirely within Smalltalk.  Nevertheless, the techniques that
they used might not work with another language.  Or rather, you
would give up compiler support and do type-checking at run-time
in the algebra package.  Nevertheless, I remember that when I
read the paper years ago that I instantly thought that this was
the right way to do symbolic algebra, and I still think that way.

Moreover, the paper offers some strong arguments that the techniques
that it describes are generally useful for object-oriented programming,
and these arguments have not received the hearing that they deserve.

Ralph Johnson -- University of Illinois at Urbana-Champaign
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.c++,comp.lang.eiffel,comp.lang.clos
Newsgroups: comp.object

In article ... kers@hplb.hpl.hp.com (Chris Dollin) (me!) writes:

   Would it be correct for me to read you as saying ``You can't have 
   multi-methods in languages which are so statically typed that no type 
   information is available at run-time''? If so, I think you are wrong, for
   two reasons.

I then gave one reason, and (because lunch called) forgot to provide the other
one. Whoops.

The other one was going to be this (in a notation which I hope is reasonably
straightforward; to be interpreted as statically typed):

    define class Base enddefine;
    define class Derived isa Base enddefine;
    define class Built isa Base enddefine;

    define method scourge( x: Derived, y: Base ) as /* case 1 */ enddefine;
    define method scourge( x: Base, y: Built ) as /* case 2 */ enddefine;
    define method scourge( x: Base, y: Base ) as /* case 3 */ enddefine;

    scourge( aDerived, aBase );		/* case 1 */
    scourge( aBase, aBuilt );		/* case 2 */
    scourge( aBase, aBase );		/* case 3 */

Sure looks like multi-method dispatch to me. Overloading? You mean compile-time
multi-methods, right :-?

    define class Bigger isa Derived enddefine;

    scourge( aBigger, aBase );		/* case 1 */

Here there are other factors to consider; is aBigger ``converted'' to a Derived
object as it is passed to case 1, or is the ``entire'' aBigger passed? It
depends on how the language is put together. I suspect Bob would have it
converted, to fit his notion of static typing, whereas I would not, because it
does not conflict with mine. (Let's not worry about the names; let's worry
about observable consequences, and hope we don't have to worry about the names
of *those*.)

The tricky one, of course, is

    scourge( aDerived, aBuilt );	/* which case? */

which fits both case 1 and case 2. Fortunately this is not a static vs dynamic
typing issue.



--

Regards,    | "If taking devious pains was a sign of laziness, he was quite
Kers.       | prepared to call Hazelton the laziest man alive." Blish (m-o-l)
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: Mon, 7 Sep 1992 00:24:27 GMT


In article <1992Sep6.003055.2236@tfs.com> eric@tfs.com (Eric Smith) writes:
>In article <graham.715679543@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>>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.

Why do people insist on using the word "lattice" here?
OOP classes usually do _not_ form a lattice. Semi-lattice maybe?

>If you insist on modelling all possible relationships at once, then yes,
>it does get complicated.  But trying to model them without OO would be
>far more complicated.

I would say that trying to modell _everything_ by means of subclass
relationships leads to _wrong_ models and _wrong_ results.
(during the workshop on Multiple Subclassing in Ecoop92 there was an 
interesting discussion on this).

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: khartig@nyx.cs.du.edu (Kevin Hartig)
Subject: Re: OO Analysis & Design Tool Review
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Fri, 11 Sep 92 14:53:54 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
>--------------------------------------

Your points are well taken. I agree that the method should drive the tool
selection. Given the current limited availability of object oriented tools
which run on specific hardware platforms, software development projects of 
today have to either forgo using tools that support object-oriented methods
or buy a tool and work with what the get.

So far my experience and perceptions of how government and private industry
have chosen specific object oriented methods for their projects is as much a
matter of personal preference and familiarity as it is how a particular method
applies to a specific problem domain.
 
For large software projects no one method is sufficient throughout the entire
analysis and design. It is best to apply appropriate methods to each part with
an overall project methodology that ties all parts together. Paradigm Plus
running on PCs support multiple methods and notation.

As a contractor supporting the government, I recommended that the Booch
method and notation be used for the top level design. Of the two tools
which implement the Booch method (Rose and Paradigm Plus) I recommended
Rose for the project. This was becuase of the development environment
(SPARCstation, UNIX, MOTIF, C++) and the fact that ROSE interfaces directly
with FrameMaker for documentation. FrameMaker is already being widely used
at this government facility. As Rose exists today, it will not be sufficient
for modeling the entire project. Other top down structured and data driven
models will be used.

The only other OOA/D tools that I know of are:

OOTool - for PCs (shareware) which employ the Coad/Yourdon method and notation,

Object-Oriented Environment - couldn't get a copy of this one
Fuji Xerox ?

Adagen  - didn't evaluate this one either.
Mark V Systems, Ltd 

Parc Place is also supposed to be coming out with an OOA/D tool.

I'm sure there are others I don't know about. Also, many more will be introduced
during the coming years.

-Kevin
 Hartig@fsl.noaa.gov

 

    




Newsgroups: comp.object
From: Goran Ericsson <ergo@incosys.kth.se>
Subject: Conferences on Object-orientation
Organization: KTH, Industrial Control Systems
X-Useragent: Nuntius v1.0
Date: Wed, 9 Sep 1992 13:38:05 GMT


From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Mon, 7 Sep 1992 08:44:18 GMT
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Organization: Hewlett-Packard Laboratories, Bristol, UK.