HDTenEightyP/NetNews huggingface dataset:
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: Fri, 11 Sep 1992 14:41:03 GMT


In article <graham.716171921@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>(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).

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

Notice also that the class produced by the above functor is an _instance_ 
of the MetaMetaClass Field, and there you define the protocol
for removing ZERO from the carrier set.

Here one can see that METACLASS is a very useful concept;
it is important that they are implemented properly.

There is one more option (which is not what I recommend, but it
can be very helpful):

Field((op1,ZERO),(op2,ONE)) :< Monoid((op2,ONE))

and you just put some additional axioms for dealing with the set
without ZERO.

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

This part is a result of my above scheme.

>Why did you not make the heirarchy
>       Ring < FiniteSet < Set

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)

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

Do you mean
      FiniteRing :< FiniteSet :< Set 
?

I have already done it.
But again, I'm afraid there might be something in your question
which was not that clear.

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: 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: Mon, 7 Sep 1992 04:29:05 GMT

James_-_Odell@cup.portal.com writes:

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

This may be, but "class" in object-oriented programming is certainly
not equivalent to set.  For example, I would never represent the
set of primes over 1,000,000 as a class.  Nor would I represent the
set of venders that sell toasters to me as a class.  In the second case
I would use an object that is really a data structure that represents
the set.  In the first I would use an object that calculates membership.
I would probably have a single class that would represent any set of
primes over N, where N was an attribute of the instance of the class.

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

I can't see how this can be true.  Else why would Smalltalk have a Set class?
Sets are distinct from classes.  In Smalltalk, every class can retrieve
the set of its instances, but that does not mean that a class IS a set,
and certainly not that a set is a class.  If the *application* wants to
treat something as a set then the designer should use a Set.  

I agree that Circle should not normally be a subclass of Ellipse.
The only reason that you would do it would be if you wanted to be
able to convert a Circle to be an Ellipse without loosing its identity
and the object notation that you were using required that an object never
change its class.  (I.e. you are using most of today's OOP languages.)

I think we had this argument a few months back.  Basically, if Ellipses
and Circles are immutable objects then it makes sense for a Circle to
be a subclass of Ellipse with the constraint that the virticle and 
horizontal axis are equal, but if these objects can change their 
dimensions then Ellipses have operations that can be performed on them
that *cannot* be performed on Circles, e.g. change horizontal axis, so
Ellipses might be a subclass of Circles, but Circles most certainly can't
be a subclass of Ellipse.  Of course, saying that an Ellipse is a subclass
of Circle might make sense from an implementation point of view, but doesn't
make sense at all from a modeling point of view.  The correct solution is
probably to have an AbstractEllipse class of which both Circle and Ellipse
can be a subclass.  In general, abstract classes are cures to many ills.

Ralph Johnson -- University of Illinois at Urbana-Champaign
From: santas@inf.ethz.ch (Philip Santas)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 14 Sep 92 14:38:31 GMT
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH


In article <graham.716452068@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>(Philip Santas) writes:
>>
>>I just decompose it into more basic parts.
>
>And in doing so impose a conceptual ordering on attributes. 
>[...] Decomposing it forces
>an ordering which is not there. If I have two attributes A and B, do
>I decompose by A first and then B, or vica-versa?

It is not important. You can do it in parallel.
As I said:
>>When you do the decomposition, you do not have limits in the order.

You just add links between the classes. When you will add them? 
Some time before you decide to run your program!

>Of course you have an order. Do you write
>       EnumSet < FiniteSet < Set
>       EnumSet < InFiniteSet < Set
>or do you write
>       FiniteSet < EnumSet < Set
>       InFiniteSet < EnumSet < Set
>Whichever way you decompose you introduce an ordering between
>Enum and Finite.

Not at all: I repeat the same things again:

    EnumSet :< Set 
    FiniteSet :< Set 
    Ring :< Set 
    FiniteRing :< FiniteSet + Ring
    FiniteEnumRing :< (FiniteSet + Ring + EnumSet) or   (here the order plays no role)
                      (EnumRing + FiniteSet)       or   (here we do have an order)
                      (EnumSet + FiniteRing)            (but why should you care?)

If you choose the 1st solution, then you leave everything up to the system to 
choose the order it wishes. This is not important at all. You can choose any order you wish,
if you want to help the compiler to do a better work: atually our system does 
this work by itself. Addition among classes obeys the axioms of commut., assoc. 0-elem.

The user should be able to add links on the fly, without caring which link to add
first and which to add second.

Suppose you have initially 3 independent classes: Set, Ring, EnumSet.
Then you add WITH ANY ORDER (or in parallel) 
      EnumSet :< Set,  
      Ring :< Set, 
you can declare 
      EnumRing::Class
and immediately after the declaration add
      EnumRing :< EnumSet + Ring

The only thing that needs to have an order is the declaration, nothing else.
You can start by EnumRing :< EnumSet + Ring and then add  EnumSet :< Set and Ring :< Set,
or just start with the declaration, and add the rest of the links IN PARALLEL.

Do you see that your problem is artificial?

Philip Santas

 "Creativity in programming is to find deep simplicities in a complex process."  
--------------------------------------------------------------------------------
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: Glenn Stauffer <stauffer@cc.swarthmore.edu>
Subject: Re: design tools
X-Xxmessage-Id: <A6D89D4E3101433A@mac8.beardsley.swarthmore.edu>
X-Xxdate: Sun, 13 Sep 92 12:25:02 GMT
Organization: Swarthmore College Computing Center
X-Useragent: Nuntius v1.1.1d9
Date: Sun, 13 Sep 1992 11:25:32 GMT

In article <1992Sep12.150752.24835@umr.edu> Brian Quandt,
quandt@mcs213c.cs.umr.edu writes:
>What OO or strucutred design tools are available (public domain) for the
>UNIX world?  I know that a tool 'easycase' is availbe for the DOS world.

I'm also interested in the availability of PD/Shareware design tools for 
Unix, DOS (where is easycase found), and Mac.

Is there a FAQ list that covers this issue?

In a related vein, which design methodology is most commonly use with OO 
design tools both commercial and PD?  I saw a review of several 
commercial design tools and it seemed that the Booch methodology was 
supported by most.  I've been studying the Rumbaugh OMT methodology and 
am wondering whether my time would be best spent studying Booch.  Is 
there a FAQ discussing the relative merits of OO design methodologies?

STAUFFER

Glenn Stauffer
Swarthmore College Computing Center
stauffer@cc.swarthmore.edu
Newsgroups: comp.object,comp.lang.c++
From: opdyke@ernie.cs.uiuc.edu ()
Subject: Refactoring Object-Oriented Frameworks
Organization: University of Illinois, Dept. of Comp. Sci., Urbana,  IL
Date: Thu, 10 Sep 1992 13:24:44 GMT

Below is the abstract of my PhD thesis, recently completed at the
University of Illinois at Urbana-Champaign, entitled ``Refactoring
Object-Oriented Frameworks.''  My research was supervised by
Professor Ralph Johnson, and builds upon research he did with
Brian Foote on Designing Reusable Classes.

The thesis is available from the Department of Computer Science as Technical 
Report No. UIUCDCS--R--92--1759.  Erna Amerman (erna@cs.uiuc.edu) is the 
department's contact for technical reports.

If you have any questions regarding this research, please contact
Ralph Johnson (johnson@cs.uiuc.edu) or myself.

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

*****

This thesis defines a set of program restructuring operations
(refactorings) that support the design, evolution and reuse
of object-oriented application frameworks.

The focus of the thesis is on automating the refactorings in a way
that preserves the behavior of a program.  The refactorings are
defined to be behavior preserving, provided that their
preconditions are met.  Most of the refactorings are simple to
implement and it is almost trivial to show that they are behavior
preserving.  However, for a few refactorings, one or more of their
preconditions are in general undecidable.  Fortunately, for some cases
it can be determined whether these refactorings can be applied
safely.

Three of the most complex refactorings are defined in detail: generalizing
the inheritance hierarchy, specializing the inheritance hierarchy
and using aggregations to model the relationships among classes.  These 
operations are decomposed into more primitive parts, and the power of these
operations is discussed from the perspectives of automatability and
usefulness in supporting design.

Two design constraints needed in refactoring are class invariants and
exclusive components.  These constraints are needed to ensure that behavior
is preserved across some refactorings.  This thesis gives some conservative
algorithms for determining whether a program satisfies these constraints, 
and describes how to use this design information to refactor a program.

Newsgroups: comp.object
From: brianm@ecst.csuchico.edu (Brian Meyerpeter)
Subject: Is there a *REAL* ORB implementation out there?
Organization: California State University, Chico
Date: Thu, 10 Sep 1992 19:25:16 GMT



As I scan the specs from OMG  (Object Management Group)  on the 
ORB  (Object Request Broker)  in my HLH (humble little home),
I ask myself,  "Has anyone actually implemented this stuff?"  Are there
companies actually working on this stuff?

I'd really like to know what you'all think about the spec and its 
ideas.  I think it looks slow, but ok for open systems.


What about object adapters and the like?

I'll repost summaries if I get enough.

Thx
Brian Meyerpeter
From: davidm@consilium.com (David S. Masterson)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 7 Sep 92 09:47:40 GMT
	<graham.715829976@galois> <1992Sep7.034245.602@tfs.com>
	<graham.715854518@galois>
Distribution: comp
Organization: Consilium Inc., Mountain View, California
In-reply-to: graham@maths.su.oz.au's message of 7 Sep 92 08:28:38 GMT
X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> On 7 Sep 92 08:28:38 GMT, graham@maths.su.oz.au (Graham Matthews) said:

> eric@tfs.com (Eric Smith) writes:

>>The trick is to see that relationships are themselves objects.  For example,
>>the ways a line and a circle can relate to each other are the line-circle
>>relationship, which is a subclass of the two-geometric-figure relationship.
>>Intersections are a feature of geometric figures, and the intersections of a
>>line and a circle are a feature of the line-circle-relationship subclass of
>>the two-geometric-figure relationship.

> Three points in reply:

> a) I find it very unnatural to think of the relationships between objects as
> objects. This is why we have two names for the two different ideas.

In the Smalltalk world, everything is an object.  Put another way, when you
can apply attributes to a relationship (in this case, the point where two
figures intersect), then maybe the relationship is also an entity in its own
right.  The classic question from E/R modelling is "what is a marriage -- a
relationship between two people or an event that occurred at a specific time
and place?"

> b) you assume that the relationships between objects can be modelled using
> your inheritance structure, or more generally that the mechanism for
> classifying the types of objects is to be the same mechanism for handling
> relationships between types. I see no reason to assume that this assumption
> is true.

Why not?  It is one model of the problem.

> c) if you have a lot of relationships your scheme gets pretty clumsy.
> Moreover many of these relationships are not naturally specified in an
> inheritance framework.

Yes, keeping track of all those potential relationships between objects won't
be pretty, but that's what E/R modelling is for.  When relating two geometric
objects, for instance, there would be a lot of double dispatching to try and
figure out what the exact relationship is.
--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
davidm@consilium.com				Mtn. View, CA  94043
====================================================================
"Politics is for the moment.  An equation is for eternity." 
-- Albert Einstein
Newsgroups: comp.object
From: chrisa@world.std.com (Chris N Anderson)
Subject: OOPSLA '92 (Vancouver) Info/Dates Needed
Organization: The World Public Access UNIX, Brookline, MA
Distribution: us
Date: Sat, 5 Sep 1992 14:01:24 GMT


No need to clutter the newsgroup with this, but I'd be very grateful
if someone could email me the announcement or just dates and
contact info for this year's OOPSLA, which I seem to have
to have misfiled.  October is coming soon to a calendar near you...

Many thanks.

---Chris Anderson
   chrisa@world.std.com

Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: Sun, 13 Sep 92 00:12:02 GMT
Organization: Object Systems

In article <BEVAN.92Sep9170738@tiger.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>   and he even went so
>   far as to claim that natural language interfaces to databases (which allow
>   anyone to easily access a database) were a bad thing!
>
>I claimed that _I_don't_like_ "English" interfaces which try and
>second guess the meaning of a query because the semantics are so
>poorly defined that it is difficult to write a logical query.
>...
  [If you enter such queries you deserve what you get, which is still better
   than the usual look of "My god, you really are that stupid" which you'd
   get if you made such a query to a person.]

Ok.  But I recently had a serendipituos encounter with a natural language
interface to databases provided by a company named "Natural Language".
I was told they have the only commercial "reasoning-based" system and
I left quite impressed (for an existing system, of course:-).  I entered
queries such as:
  "Please give me all of the SysCo employees who make over 500 dollars a week,
   work in San Fransisco and are over 35."
Whereupon the SQL generated by this query was displayed (and can be modified).
The results of the query were then presented in a nice table.  Nothing
ambiguous about it, anyone could use it (little to no training time), and
if you don't like it or what it generates, SQL can still be entered or you
have the option of modifying the generated SQL (which is unambiguous).  I could
immediately see this used in banking (which was the application domain) where
instead of waiting 3 weeks and paying some ridiculous fee for a simple account
summary and then getting loads of the wrong information (with a little right
information) sent to me, I (or anyone) could sit down with some proper bank
employee and enter the query *myself* since the interface is so much better
than forcing some SQL-like entry.  So I could enter: "Give me all transfer and
withdrawal transactions on my savings account over $300 between Sept 1 and
Sept 9" and whalah, a nice table of these transactions appears before my eyes.
If it can't disambiguate the query, it'll just ask you to be more precise (as
does anyone else or any compiler/translator).

I'm writing this so readers can see the advantage of such an approach (which
is clearly in our best interests) and because *IMHO* such interfaces will
provide (or at least be a part of) the next generation of database interfaces.

bob
objsys@netcom.com
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.object
Subject: Re: Can AX substitute for A?
Date: 15 Sep 1992 20:35:12 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com
Keywords: signature

In article <42712@ogicse.ogi.edu> riks@ogicse.ogi.edu (Rik Fischer Smoody) writes:
>In the above, don't get side-tracked by the unlikely "sub-classing".  
>    Whether an object of class B can fill in for one of class A in some 
>    context is only coincidental with inheritance.
>    Let's please keep code sharing at least partially separated from appropriateness
>    for a given context.
>Besides, ANY accurate model of the above systems would show the incompatibility
>The conclusion I draw is that the programming environment should NOT 
>    promote  computer-guessed substitutability.  If it just so happens that 
>    the new kinds of objects CAN use an existing method, that's gravy. It 
>    should be easy to say which existing method.

In most OO programming languages, subclassing is used to model IS-A
relationships, and hence implies substitutability.  I think it's wrong to
use analogies to the real world that don't fit this model, and then just
brush it off by calling it "coincidental".  The assumption in OO
programming is that the ability to reuse inherited code is a *consequence*
of the relationship that also guarantees substitutability, not something
that "just so happens".



-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.object
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Organization: University of Jyvaskyla, Finland
Date: Tue, 15 Sep 1992 10:04:26 GMT

In article <a8wnd++.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
>In article <KERS.92Sep7094418@cdollin.hpl.hp.com>, kers@hplb.hpl.hp.com (Chris Dollin) writes:
> ...
>>[I'm sure I've asked you this before, Bob, but what's the difference between a
>>``dynamic'' function and a ``static'' one?]
>
>Whether the method/function selection is performed at compile-time (static
>typing, e.g. C++, Eiffle) or at run-time (dynamic typing, e.g. CLOS, Smalltalk).
> ...

Oh dear.  Method/function selection is certainly performed at run time
in both C++ (although only for virtual functions) and Eiffel.
The difference is that Smalltalk and similar languages have
dynamic ad-hoc polymorphism: any method that just happens to have the same
name will gladly be invoked.
Statically typed OOPLs usually have dynamic inclusion polymorphism:
only functions defined on more or less the same inheritance path
are eligible.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 12 Sep 1992 03:20:37 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com
Keywords: signature

In article <5740@osc.COM> Joe Keane <jgk@osc.com> writes:
>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)?

Yes, this can be a problem.  The solution CLOS takes is arbitrary, but
pretty simple: there's a precedence order to the arguments (left-to-right
by default, but the definition of a generic function can override this).
So, in the default case, M(AX,BY) would invoke M(AX,B); if it calls
CALL-NEXT-METHOD this will invoke M(A,BY), and if this calls
CALL-NEXT-METHOD it will invoke M(A,B).

Things are simplified if the classes are defined in mixin style, using
:BEFORE and :AFTER methods for the X and Y mixin classes, rather than
shadowing the M method totally.  In that case, the standard method
combination facility will arrange for all the methods to run automatically.

The metaobject protocol can be used to define other conflict resolution
schemes, including signalling an error due to the ambiguity.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar