HDTenEightyP/NetNews huggingface dataset:
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 06:27:48 GMT

(Philip Santas) writes:
>
>class Field((op1,ZERO),(op2,ONE)),
>                  ^^^^^^
graham@maths.su.oz.au (Graham Matthews) writes:
>>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:
>What is the case?

Group is Set with +
Ring is Group with *
Field is Ring with /

No mention of a zero.

(Philip Santas) writes:
>You may try:
>Field((op1,ZERO),(op2,ONE)) :< Ring((op1,ZERO),(op2,ONE))
Graham:
>>               FiniteRing < FiniteSet < Set
>>               NonFiniteRing < NonFiniteSet < Set
(Philip Santas) writes:
>This looks correct.
>But why don't you decmpose it into its parts?
>    FiniteSet :< Set
>    Ring :< Set
>    FiniteRing :< FiniteSet + Ring

Because I do not wish to decompose it at all. 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?

Graham:
>>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? 
(Philip Santas) writes:
>The above scheme poses no problems. I just decompose it into more
>basic parts.

And in doing so impose a conceptual ordering on attributes. No thanks.

Graham:
>>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.
Phillip:
>When you do the decomposition, you do not have limits in the order.
>Do you want to have an enumerable Set?
>    EnumSet :< Set
>Notice that the order in which I add these links is not important.
>Important is to have them.

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.

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: alext@cix.compulink.co.uk (Alex Thomas)
Subject: Re: RFI: ISA/ANSA ?
Reply-To: alext@cix.compulink.co.uk
Date: Tue, 8 Sep 1992 17:54:00 +0000


ANSA is a Cambridge,UK company with an established line of
distributed system s/w platforms known as Ansaware. They are also
involved with the OMG's work.

I don't have conventional contact info to hand but I have the Email
address of one of their guys - Hugh Tonks ht@ansa.co.uk. Hope this
helps.

[ISA - not ISC (The Eiffel co.?)]


Alex Thomas
alext@cix.compulink.co.uk

BTW this is my first net posting - start by being helpful, right?
-----------------------------------------------------------------------
Have you explained this to YOUR parents?
-----------------------------------------------------------------------
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 10 Sep 92 15:41:59 GMT
	<graham.715918116@galois> <1992Sep8.183152.9350@neptune.inf.ethz.ch>
	<graham.716002888@galois> <1992Sep9.095527.11456@m.cs.uiuc.edu>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 9 Sep 92 09:55:27 GMT, johnson@m.cs.uiuc.edu (Ralph Johnson) said:

johnson> (Graham Matthews) writes:

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

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

johnson> For an example of how to handle this, see "A Smalltalk System
johnson> for Algebraic Manipulation" in OOPSLA'86.  Note that, strictly
johnson> speaking, they had to extend Smalltalk to get the language
johnson> features that they wanted, though Smalltalk is flexible enough
johnson> that they could do it entirely within Smalltalk.

Well, you can achieve *exactly* the same result in Fortran IV, just as
you can do structured programming in assembler.

Maybe what matters is not what you can simulate (e.g. multiple
inheritance in Smalltalk), but what you offer as "primitives", first at
the conceptual level, and then at the language level. But I have so much
difficulty getting this observation across at times; for example my well
known stance against rabid optimization in C or fortran is based on the
idea that it is a poor attempt to turn C or fortran into numerical
processing or vector languages, when they are really implementation
languages for such an application oriented level. So, for example, what
amazes me of Coplien's book is that it is considered as an example of
the idea that C++ can support anything, while instead it is really an
example of the idea that you have to constantly fight against C++ to
support anything at all.

johnson> Nevertheless, the techniques that they used might not work with
johnson> another language.  Or rather, you would give up compiler
johnson> support and do type-checking at run-time in the algebra
johnson> package.

Ah precisely. You blur the distinction between application language and
implementation language. Might be OK, might be not.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.object
From: richieb@bony1.bony.com (Richard Bielak)
Newsgroups: comp.object,comp.lang.eiffel,comp.lang.smalltalk
Subject: Re: Future Issues of Object Orientation
Date: 3 Sep 92 12:21:27 GMT
Distribution: usa
Organization: multicellular

In article <923@ast.dsd.northrop.com> 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?
>

OK. Here is my list.


   - OO Databases

     I think the problem of OO databases is well understood, but
     current implementations are immature. They have to improve
     quite a bit.

     One research problem with OODB is the design of a query
     language. There was an interesting paper on this topic presented
     at the last TOOLS USA conference, which basically said: SQL is
     _not_ it. 


   - Concurrency and distributed objects

     At this time none of the main stream OO languages supports
     concurrency. In fact, there is not a single model of OO concurrency
     widely accepted - eg. one thread of control per object or many?

     Currently there is little support for transporting objects
     around networks and for "remote-method-invocation".


   - OO Operating Systems

     In such a system, you don't make calls to kernel routines, but
     talk to objects which are various system components. In an
     OOO/S (!) the smallest execution unit would be an object. You could
     replace objects dynamically, without having to re-link programs.
     In fact there should be no such thing as linking.


   - Inheritance

     What is inheritance? Subtyping? Subclassing? "Is-a" relationship?
     Module extension hack? 

     I think we still have some way to go before understanding fully
     the meaning of inheritance.



...richie
-- 
* Richie Bielak   (212)-815-3072   | "Your brain is a liquid-cooled parallel  *
* Internet:       richieb@bony.com | super-computer". He pointed to his nose, *
* Bang {uupsi,uunet}!bony1!richieb | "This is the fan."                       *
*    - Strictly my opinions -      |                     - David Chudnovsky - *
From: timothy@eddie.rmNUG.org
Newsgroups: comp.object
Subject: ParcPlace Systems new OO System
Date: 8 Sep 92 14:55:27 GMT
Followup-To: timothy@eddie.rmnug.org
Organization: Rocky Mountain NeXT Users' Group


Just got an invitation for a Technology Introduction Seminar from  
ParcPlace regarding the VISUALWORKS OO Development environment.

They claim that this is a comprehensive Object Oriented Development  
environment that:
	*Eliminates the learning curve of OOP
	*Provides compiled program performance
	*Has the dynamic features of Smalltalk
	*Includes a state of the art multi-platform GUI builder
	*Has built in RDBMS connectivity
	*Allows for migration to real-time systems

The platforms supported are:
Open Look 
Motif
Windows 3.1
Presentation Manager
Macintosh
Sequent
Dec
IBM Risc 6000
Hewlett Packard
IBM
SUN
NeXT
NeXTStep
Macintosh

Anybody have any more information on this?

Tim
-- 
[] Tim Miller  []  MS-IS Student  []  CU Boulder []
[] NeXTmail: timothy@eddie.rmNUG.org []
[] Life is a lattice, we only model it as a hierarchy. []
Newsgroups: comp.object
From: eric@tfs.com (Eric Smith)
Subject: Re: Can AX substitute for A?
Keywords: signature
Organization: TFS
Date: Tue, 15 Sep 1992 07:11:42 GMT

In article <42712@ogicse.ogi.edu> riks@ogicse.ogi.edu (Rik Fischer Smoody) writes:
>Let's start with fasten(screw, hole-in-the-wood).  We could substitute a 
>    nail...then we normally just whack it with a hammer instead of turning 

The base class of screw and of nail is fastener.  Your whole idea amounts
to a desire to use the derived classes without formalizing the base class.
The cost of doing it that way would exceed the gain, mainly because nothing
is really gained other than allowing a little less formality.
From: tmhoff@oogoody.Corp.Sun.COM (Todd Hoff)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class S
Date: 11 Sep 1992 17:00:14 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: tmhoff@oogoody.Corp.Sun.COM
NNTP-Posting-Host: oogoody.corp.sun.com

In article 92Sep10165302@aberdb.aber.ac.uk, pcg@aber.ac.uk (Piercarlo Grandi) writes:
>Applause, applause! The data structures within programs are as rule as
>omplex and sophisticated as those within a databse, and program design
>requires *excatly* the same conceptual tools aand attention to data
>esign as setting up a database. Suggestion seconded!
>...
>Incidentally, that's how I tend to attack data design issues in my
>programs (yes, I often do *informal* relational schemas and then I map
>them onto records and pointers and hash tables and trees and whatever).

I'll go a step farther and say all programming (at some level) is really database 
programming, people just don't generally look at it that way. Hash tables, 
doubly linked lists, structures, etc. are incredibly primitive and limiting. 
Progammers routinely need database like facilities yet have to build tons of 
infrastructure just to get the most basic database functions. How often do you 
really want an array? Wouldn't you rather have a well defined table sporting a
data dictionary with various keys and a general query language? Isn't
that better than iterating over a link list of objects? Not to mention 
transactions, locking, persistence, etc.. I would like to work in active database
where I get to mark what data structures are ephemeral or persistent, yet
access and manipulate everything the same way. A lot of productivity is sapped
by reinventing the wheel at every step.

Newsgroups: comp.object,comp.lang.misc
From: antero@csr.UVic.CA (Antero Taivalsaari)
Subject: Kevo
Originator: antero@csr
Organization: University of Victoria, Victoria, BC, Canada
Date: Mon, 14 Sep 92 21:51:32 GMT

The beta version of a new experimental prototype-based 
object-oriented system Kevo (version 0.9b2) is now available 
by anonymous FTP from: 

	ursamajor.uvic.ca (128.189.88.151)
	directory: /ursa/kevo

Unlike most other object-oriented systems, Kevo does not have
classes. And unlike some other prototype-based systems (such as
Self), Kevo does not support delegation. Instead of classes and 
delegation, Kevo is based on _concatenation_: unlimited composition 
of object interfaces. In general, the Kevo system is a combination 
of the following ideas:

	- self-sufficient objects,
	- the use of part-whole hierarchy as a basis for 
	  system organization,
	- automatic management of inheritance hierarchies,
	- inheritance by copying and subsequent modification
	  (concatenation),
	- visual cut-copy-paste editing of objects,
	- runtime modification of the system by change propagation.

In addition to the above mentioned features, Kevo supports multitasking 
and has several reflective facilities such as decompilation, execution
tracing, and a simple debugger.

Kevo runs currently on Macintoshes (with 68020 or later). System 7
is recommended, although there should be no problems with older
Mac OS versions with Multifinder. Kevo creates a lot of windows,
so a large screen is needed.

The FTP directory contains the (binhexed and compressed) executable, 
some demo programs, a user's guide, and a few papers about the system. 

The Kevo system is a research work which is provided 'as is' without 
any warranties or visible support. For further information, send 
comments and questions to: kevo-interest@ursamajor.uvic.ca.

-- Antero Taivalsaari
   antero@csr.uvic.ca

Newsgroups: comp.object
From: bhatia@moscow.uucp (25581-bhatia)
Subject: Re: objects and testing
Organization: Bellcore, Livingston, NJ
Date: Mon, 14 Sep 92 19:51:44 GMT

In article <Btw7wq.Fuv@cs.vu.nl> lex@cs.vu.nl (Hagel AP) writes:
>We, two students of computer science at the Vrije Universiteit,
>are doing research on testing of software and in particular testing of
>software which is object-oriented. The purpose of our research is to gain 
..............
.....
>We would be very much obliged to receive information on testing and/or
>articles on these subjects.
>
>Vrije Universiteit                            E-Mail: lex@cs.vu.nl
...
>
>Marcel de Groote                              E-Mail: mdgroot@cs.vu.nl
....


--------------------------------------------------------------------------

There is an excellent coverage of testing for object oriented software in:

"Object Oriented Software Engineering ( A Use Case Driven Approach)"
by Ivar Jacobson,
Addison Wesley Publishing Co, 1992

This book has an entire chapter specifically devoted to OO system testing.

Raman Bhatia
From: pfkeb@kaon.SLAC.Stanford.EDU (Paul Kunz)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 6 Sep 92 04:33:54 GMT
Organization: Stanford Linear Accelerator Center
In-reply-to: p00058@mail.psi.net's message of 31 Aug 92 12:56:09 GMT

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
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class S
Date: 13 Sep 92 21:47:13 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 11 Sep 92 17:00:14 GMT, tmhoff@oogoody.Corp.Sun.COM (Todd Hoff) said:
NNTP-Posting-Host: oogoody.corp.sun.com

tmhoff> (Piercarlo Grandi) writes:

pcg> The data structures within programs are as rule as omplex and
pcg> sophisticated as those within a databse, and program design
pcg> requires *excatly* the same conceptual tools aand attention to data
pcg> esign as setting up a database.

tmhoff> I'll go a step farther and say all programming (at some level)
tmhoff> is really database programming, people just don't generally look
tmhoff> at it that way.

Ah damn, you have stolen my next line! :-)
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
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, 7 Sep 1992 01:39:36 GMT

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.

In <1992Sep6.003055.2236@tfs.com> eric@tfs.com (Eric Smith) writes:
>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.

Of course I am interested in modelling them all at one (or more precisely
I cannot predict what relationships my user will want to model so I must
cater for all possibilities). Now trying to model these relationships
without OO will indeed be very difficult, but with OO it is very difficult
too, but for a different reason. OO gets me up and running modelling some
sorts of relationships, but that is all it does. There are many many
more relationships that I cannot model with inheritance, so I am
suggesting that people need to look very carefully at inheritance. Adding
meta-typing/classing to a class heirarchy helps to some degree, but 
still ... the challenge is in modelling the relationships between objects,
not in modelling the objects themselves. In my opinion OO does a good job
of the latter and a poor job of the former.

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.lang.smalltalk,comp.lang.eiffel
From: holen@xilinx.com (Victor A. Holen )
Subject: Re: Future Issues of Object Orientation - ?Self?
Organization: Xilinx Inc.
Distribution: usa
Date: Fri, 11 Sep 1992 17:11:33 GMT

In article <> hoelzle@Xenon.Stanford.EDU (Urs Hoelzle) writes:
>....
>This is a little bit of an overstatement: not all Self programs
>approach C speed (yet :-).  However, on the (C-like) Stanford integer
>benchmarks Self does very well.  
>....
  Where can I find any info on Self ?  Is it related to Stanford's SAIL
  and to MainSail ?
thanks.


-- 
 victor ....  ___  ._..  .  _.     holen@xilinx.com
Newsgroups: comp.object
From: adykes@jpradley.jpr.com (Al Dykes)
Subject: PARTS development package
Organization: Unix in NYC
Date: Sat, 05 Sep 1992 11:01:05 GMT

Has there been any discussion of a package called PARTS, from Digitalk ? 
If someone can point me to an archive of the discussion i'd appreciate it.

Thanks


Al Dykes
---------------------------
adykes@jpr.com
Newsgroups: comp.object
From: ctaylor@dakota (Cal Taylor)
Subject: Re: RFI: ISA/ANSA ?
Organization: U S WEST Advanced Technologies
Date: Sat, 12 Sep 1992 02:35:12 GMT

In article <1992Sep5.084712.1@woods.ulowell.edu> perezc@woods.ulowell.edu writes:
>	I was just wondering if anyone knew what ISA and ANSA stands for
>in the context of OMG work.  

ANSA stands for Advanced Networked Systems Architecture.  The ANSA project
is a UK effort that got started in the mid-80s.  It subsequently became an
EC ESPRIT-funded project known as Information Systems Architecture (ISA),
but only the EC bureaucrats use that name.  Most people still refer to it
as the ANSA project.  In the future it will be funded by private sponsors
who include DEC, HP, British Telecom, Bellcore, BNR and several others I
can't name off the top of my head.

ANSA has provided the intellectual foundation for the joint ISO/CCITT
standardization activity called Open Distributed Proecssing (ODP).  My
articles in the June-July and August-September issues of the OMG 
newsletter "First Class" explain what ODP is all about.

The OMG is an industry consortium trying to promote the use of object
technology and foster interoperability between object systems.  Early on
they realized that fundamental to this goal was a problem in distributed
processing; the result is CORBA.  ANSA project contributors had an
influence on this work (although not enough IMHO) but they continue to
work with the OMG technical committees.

For more information about ANSA you can contact the Chief Architect,
Andrew Herbert, ajh@ansa.co.uk.

Hope this helps.


Cal Taylor
U S WEST Advanced Technologies          ctaylor@advtech.uswest.com
4001 Discovery Drive                    Voice: +1 303 541 6369
Boulder, CO 80303, USA                  FAX:   +1 303 541 6384
Newsgroups: comp.object
From: eric@tfs.com (Eric Smith)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: TFS
Date: Mon, 7 Sep 1992 23:33:27 GMT

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

I think we have dozens of names for them.  So what?  Maybe we should
change the terminology to use the word "idea" instead of "object",
because "object" implies something physical.  Then we could call it
IOP instead of OOP, and people would stop making jokes about how the
whole thing is a goof, oops.

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

For example, a specific relationship is a subclass of relationship,
because it "is a" relationship.  Q.E.D.  The same logic carries from
specific relationships to more specific relationships.  e.g., the
relationship between two animals is a base class of the relationship
between a bear and a bobcat, because the bear-bobcat relationship
"is a" two-animal relationship.  And the relationship between a bear
and a salmon is a subclass of the mammal-fish relationship, because
it "is a" mammal-fish relationship.  And the mammal-fish relationship
itself is a subclass of the two-animal relationship.  So you start to
see a tiny part of a vast inheritance structure of relationships.

Furthermore, program logic fits neatly that way.  There are a lot of
ways mammals in general are related to fish in general, so why repeat
that program logic for each subclass of that relationship, when you
can just inherit it from the base class?

>
>c) if you have a lot of relationships your scheme gets pretty clumsy.

Especially if you try to do it without OOP.

>Moreover many of these relationships are not naturally specified
>in an inheritance framework.

Prove that by giving a specific example.  Or don't bother, because I
already disproved it above.