HDTenEightyP/NetNews huggingface dataset:
From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: AT&T
Date: Fri, 4 Sep 1992 07:35:37 GMT

From article <rmartin.715531442@thor>, by rmartin@thor.Rational.COM (Bob Martin):
> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
> 
>>Draw is definitely more debatable.  My guess is that if you ask a Circle
>>to draw on a window, it just performs the DrawCircle operation on the
>>window, which isn't all that bad.  But in general, different applications
>>will want to draw on different things, and will want to interpret drawing
>>differently.  Is color needed? Line-width?  Neither of these are attributes
>>of Circles, so it seems unreasonable to make Circles be responsible for
>>drawing.
> 
>>In Smalltalk, there is a separation between geometric objects and
>>graphical objects.  A circle is not displayable.  Instead, you have
>>to put a wrapper on it that includes color and line width information,
>>as well as the display operations.
> 
> If Circle is a member of a family of objects which know how to draw

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.

> themselves on a Window, then the knowledge of Window by Circle is
> proper.  One could argue that the family itself was improperly
> coupled, since it represented two fundemental abstractions:  One, a
> set of geometric objects.  And two: A set of objects which can be
> drawn on a window.  It could enhance the reusability of the family if
> the concept of the window were removed from the family, and some other
> method were applied to allow drawing on the window.
> --
> Robert Martin                        Training courses offered in:
> R. C. M. Consulting                       Object Oriented Analysis
> 2080 Cranbrook Rd.                        Object Oriented Design
> Green Oaks, Il 60048 (708) 918-1004       C++

Nick Hounsome
AT&T Network Systems UK Ltd.
att!mlgtw!mltsa!nh
Newsgroups: comp.object
Subject: Re: OMT CASE Tool for MS Windows
From: lagrone@mcopn3.dseg.ti.com
Date: 3 Sep 92 07:36:26 CST
Organization: Texas Instruments Defense Systems & Electronics Group

In article <5690@npg-sd.SanDiegoCA.NCR.COM>, billc@npg-sd.SanDiegoCA.NCR.COM (Bill Canning) writes:
> In article <1992Aug29.010916.27496@ntmtv> irvine@ntmtv.UUCP (Chuck Irvine)
> writes:
>>Does anyone know if there are CASE tools based around Rumbaugh's
>>OMT OOA/D methodology for MS Windows 3.x? Same question for Booch? 
>>Thanks.
> 
> A tool you may want to try is Paradigm Plus from ProtoSoft in Houston, TX. 
> (phone 713-480-3233). It provides OO design support for both Rumbaugh and 
> Booch methodologies (as well as others). There is an MS Windows and a SUN
> OS version available at the present time.
> 
> Bill Canning
> ADE Business Unit
> NCR San Diego
>>

  There is also a product from Palladio Software in Wisconsin that supports
  Booch (but nothing else).  Sorry, I don't have the contact data with me;
  but they have an add in the September (August?) issue of Computer Language.

  The product is $495 and seems to fully support Booch as documented in 
  "Object Oriented Design with Applications".

  Hope this helps!

				...Regards...David 

david_lagrone@dseg.ti.com
Texas Instruments, Inc.
Dallas, Texas

Xref: sparky comp.object:3318 comp.lang.clos:727
From: doug@monet.ads.com (Doug Morgan)
Newsgroups: comp.object,comp.lang.clos
Subject: Re: Beginner's Question - CLOS
Date: 25 Aug 92 17:54:15 GMT
	<1992Aug19.213818.21709@tfs.com>
	<DCMARTIN.92Aug19151550@fascet.msi.com>
	<170fu1INNmfh@early-bird.think.com>
	<PCG.92Aug21005641@aberdb.aber.ac.uk>
	<DAVIS.92Aug24110309@reaumur.ilog.fr> <DOUG.92Aug24104842@monet.ads
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300

In article <DAVIS.92Aug25103247@reaumur.ilog.fr> davis@reaumur.ilog.fr (Harley Davis) writes:

   The interesting optimization that was originally mentioned was
   *statically* resolving generic function calls, not optimizing dynamic
   dispatch.  To do this, you have to guarantee that the class hierarchy
   is fixed and that all the methods attached to the generic function are
   known.  Then, in some cases, you could resolve dispatch at
   compile-time.  I suspect that most implementations already do a fairly
   good job of optimizing dynamic dispatch in the ways you mention.

I never mentioned "dynamic dispatch."  I said "I suspect the CL spec,
as is, allows for an automatic system building tool with dispatch
optimizations that are based on the entire type graph and are capable
of being *dynamically* maintained in the face of class graph changes."
("Dynamic" never modified dispatch.  Rather, "dynamically" applied to
the *maintenance* of whatever collection of dispatch mechanisms you
use.)  The dispatch optimization with the biggest bang is precisely
statically resolving generic function calls (especially to the point
of inlining small methods) and that is precisely what I was trying to
say that the CL spec allows.  I was, for instance, arguing that CL
supports compiling static resolution of dispatch at one time, noticing
that the class graph later changes, and then recompiling the user code
that previously compiled into static dispatch to now do dynamic
dispatch.  Another possible dispatch optimization (dynamic this time)
would be to generate method dispatch tables (shades of C++) for
generic functions that currently only effectively specialize on one
argument.

I do agree that this would only make CL bigger, more complicated, and
even subject to more strange run-time behaviors.  It goes against your
reasonable desire for "small" lisps.  However, some people might go
for the possibility of truly blazing speed combined with the full
run-time flexibility of standard CL/CLOS.

doug
--------------------------------------------------------------------
Doug Morgan, doug@ads.com, (415) 960-7300
Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
1500 Plymouth St., Mountain View, CA 94043-1230
--------------------------------------------------------------------
Newsgroups: comp.object
From: mw@ki.fht-mannheim.de (Marc Wachowitz)
Subject: Re: Implementation Question
Date: Wed, 02 Sep 92 14:33:08 GMT
Organization: Fachhochschule fuer Technik Mannheim
X-Newsreader: Tin 1.1 PL4

Graham Matthews <graham@maths.su.oz.au> wrote:
: 	class A
: 		instance variables a, b, c;
: 	end class;
: 
: 	class B
: 		subclass of class A;
: 		instance variables e, f;
: 	end class;
: Now my problem is as follows. How do OO implentations handle the 
: space allocation for an instance of class B? Does an instance of B
: have to have space allocated for all the instance variables in B as 
: well as all the instance variables in all the classes of which B is 
: a sub-class (in this case class A).
As subclassing is usually understood, that's exactly what you asked the system
to do. B is a subclass of A simply means that each instance of B is also of
type A, and thus should have the instance variables (assuming classes act both
as type specifications and as implementation descriptions).

The usual solution would be to change your class relations appropriately; e.g.
create an abstract class (i.e. one which isn't supposed to be instantiated)
with the features of A to be shared with B, then make both A and B subclasses
of the newly created class (removing the shared features from A, of course).
This shouldn't affect old code, and you are telling the system what you really
want.

-------------------------------------------------------------------------------
Marc Wachowitz, mw@gandalf.ki.fht-mannheim.de, 75742@novell1.rz.fht-mannheim.de
  *  wonder everyday    *    nothing in particular    *    all is special  *
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 3 Sep 1992 03:18:01 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <j8knsmd.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
>But the lack of default protection means no multiple-implementations per
>type; a severe restriction that I doubt even CLOS' intercessory protocols
>can overcome.  Am I wrong here?  Can CLOS provide for the separation of
>types and classes (or any kind of multiple implementations per type)?

While CLOS permits unrestricted access to slots (using SLOT-VALUE and
WITH-SLOTS), it certainly doesn't force it, and it's generally considered
bad style for non-methods to do so.  For large scale protection, the
package mechanism is recommended; among related classes within a package,
abstinence is the safest way.

CLOS makes it easy to define accessor methods for slots.  Such methods are
indistinguishable from ordinary methods, and can be overridden using
DEFMETHOD in subclasses.  WITH-ACCESSORS is provided as a convenience, so
that you can pretend you're accessing these slots as variables, but you're
still using the OO virtual function mechanism.

So long as all functions outside the class implementation make use of the
functional interface to slots, the separation of interface specification
and implementation can be maintained.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Xref: sparky comp.object:3381 comp.lang.clos:768
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.object,comp.lang.clos
Subject: Re: Implementation Question
Date: 2 Sep 92 16:49:04 GMT
Article-I.D.: early-bi.182ra0INN33d
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <graham.715435125@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>Now my problem is as follows. How do OO implentations handle the 
>space allocation for an instance of class B? Does an instance of B
>have to have space allocated for all the instance variables in B as 
>well as all the instance variables in all the classes of which B is 
>a sub-class (in this case class A). I ask this for three reasons :-

In most OO languages (e.g. CLOS, C++, Smalltalk, Flavors), instances of a
subclass have storage for all their own instance variables as well as for
their superclasses' instance variables.

>a) I have many examples where B is a subclass of A but one rarely
>utilises this feature. All the time is spent computing with instances
>of B as instances of the sub-class B and not as instances of the 
>super-class A. So I do not want to allocate space for any instance 
>variables (in this case those in class A) which I am rarely if ever 
>going to use.

Do you know at object creation time whether you'll care about its A nature?
If so, you could create two classes, one that inherits from A and one that
doesn't, and allocate the appropriate kind.

CLOS permits objects to change their class dynamically.  You could create
the object as an instance of the non-inheriting class, and when it becomes
apparent that you'll be doing things that care about the superclass it
could use CHANGE-CLASS to transform itself to the inheriting class.

>b) I have example code where the representation of B is not the
>same as A. That is mathematically B is a sub-type of A but for
>various reasons the implementation of B does not have any of the 
>slots of A.

This is the distinction between inheriting behavior and structure.  Most OO
languages use the same mechanism for both, thus making it tricky to do what
you want.

However, it's often possible using multiple inheritance.  You split a class
into two classes, one that represents the behavior and the other that
implements a particular structure.  A-behavior could be an abstract base
class in languages that support that notion.  You can then define B as a
subclass of A-behavior, and it won't inherit from A-structure.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: 26 Aug 92 12:44:57 GMT
	<KERS.92Aug20120508@cdollin.hpl.hp.com> <1#_n4_m.objsys@netcom.com>
	<KERS.92Aug211506 <KERS.92Aug25085105@cdollin.hpl.hp.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 25 Aug 92 07:51:05 GMT, kers@hplb.hpl.hp.com (Chris Dollin) said:

kers> (Ralph Johnson) writes:

johnson> [responding to me, and this time I've killed the context]

johnson> The point I am trying to make is that no model is completely
johnson> accurate, even computer ones.  Describing a system with any
johnson> formal language will always be incomplete.  That's life.  The
johnson> question is whether one model is more complete, easier to
johnson> understand, executes faster, etc. than another, not whether
johnson> either is perfect.

kers> Yes, and I hope I don't seem to be contradictory if I agree with
kers> this (and the other things you said in your post). Part of my
kers> argument with Bob H was about his presumed belief that a
kers> particular OOP model of objects, extended in some way (for
kers> example, adding concurrency), was the *right*, *true*, and
kers> *natural* way of describing the world.

I have this delightful quote to offer:

  _If I hear the phrase 'everything is an object' once more, I think I
  will scream._ (Stonebraker, 1988)

If he is reading this group he will have lost his voice by now :-).
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: Tue, 01 Sep 92 22:43:57 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Summary: RWM
Orgonization: Object Systems

In article <a6bb2744@infoage.com>, bradcox@infoage.com (Brad Cox) writes:
> Chris writes:
>> What I *do* deny is that the ``natural'' way we see the world and our
>> programs means that the underlying structure of the world is necessarily
>> ``like that'', and that object models are more than an analogy for the
>> world -- and that they are *worse*, for the purposes of understanding
>> the world, than other models that we *do* have.
>
>Could this be the distinction you're belaboring? Computer-resident
>objects invoke each other unilaterally. Objects in the real world
>communicate bilaterally; through satisfaction of bi-directional
>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
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Implementation Question
Date: Wed, 02 Sep 92 23:56:53 GMT
Organization: Object Systems

In article <hoelzle.715461389@Xenon.Stanford.EDU> hoelzle@Xenon.Stanford.EDU (Urs Hoelzle) writes:
>>...
>Exactly.  And I can't resist mentioning that Self does The Right Thing (TM)
>- with the nice side effect that no code ever depends on the format
>of an object (i.e. whether is has an x instance variable or an x
>method).

I like Self's prototyping abilities too but IMHO they are too unstructured.
They are on the right track but *I* wouldn't refer to Self as "The Right
Thing" but more as an advanced and available seminal vehicle certainly
providing some of the "Right Facilities".

bob
objsys@netcom.com
Newsgroups: comp.object
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Reply-To: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Organization: Bell-Northern Research, Ottawa, Canada
Date: Wed, 2 Sep 1992 14:00:48 GMT

In article <43008@skye.dcs.ed.ac.uk>, rjp@dcs.ed.ac.uk (Rob Pooley) writes:
> 
> You define any class in the context of its use. Any methodology that
doesn't know
> this is going to take you down the same old blind alleys as past
"problems" with
> OO techniques. I make draw into a method of circle if that helps me
build my package
> in a way that is easy to understand and to use.

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?

Stuart

: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
From: aew@eosvcr.wimsey.bc.ca (Alan Walford)
Distribution: world
Date: Wed, 02 Sep 92 07:54:01 PDT
Organization: Eos Systems Inc, Vancouver, B.C., Canada

"Ronald C. Schultz" <p00058@mail.psi.net> writes:

> Object Coupling - In order to better support reuse, objects should be as 
> decoupled as possible from any specific application, so that they may be 
> reused in as many applications as possible.  In Rumbaugh's OMT text he 
> provides a class specification for a circle on page 290.  I quote:
> 
> ---- 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 --------------------------
> 
> This class specification screams of unnecessary object coupling.  Why, 
> for instance, should a circle need to be aware of the existence of 
> lines? or of the existence of windows?  To me, this class violates the 
> very concept of a circle as defined in any geometry text.    
> 

My feeling is that Draw should not be in the class. An operation that
is very dependent on a user interface should be decoupled from a model 
class like "Circle". Draw should be in a UI class like a "View". You can
see I follow the Model-View-Controller (MVC) paradigm quite a bit.

My question is where does intersectLine go?  Does it go with Line, with
Cirlce, with an application View or with some other class ? 

It should _not_ go with the application since line and circle intersection 
is application independent. One would not want this sort of coupling to an
application (loss of reuse). But if you do not like it going with Circle or
Line, where does it go?  A Transform class perhaps ?

Al
----------------------------------------------------------------------------
Alan Walford     Eos Systems Inc., Vancouver,B.C., Canada  Tel: 604-734-8655
aew@eosvcr.wimsey.bc.ca  OR  ...uunet!wimsey.bc.ca!eosvcr!aew
From: rjp@dcs.ed.ac.uk (Rob Pooley)
Newsgroups: comp.object
Subject: Re: problems with SIMULA under DOS
Keywords: SIMULA, DOS, GRAPHICS
Date: 1 Sep 92 14:55:10 GMT
Organization: Department of Computer Science, University of Edinburgh

In article <10834@asterix.informatik.uni-kiel.dbp.de>, mas@informatik.uni-kiel.dbp.de (Meinolf Asshoff) writes:
> Hello everybody,
> does anyone work with SIMULA on PCs under DOS (or Windows) ?
> We just got a version from Simula a.s. in Oslo, Norway, 
> distributed by SIMULA-Team in Dortmund, Germany. Its a mess, 
> it doesn't work with the simplest examples. The test programm runs,
> but when we insert something simple or delete for instance one of 3
> instructions of the same kind the computer breaks down. Sometimes
> renaming of a file removes the problems ...
> 
> - Have you made your own experiences with this version ore are there
>   other implementations of Simula for DOS ?
> - Or do you know Simula classes for graphical presentation under VMS
>   that we might use on our microVax ?
> 
> Please let me know, we are in trouble.
> 
> Thanks, Meinolf Asshoff
> 
>

In case this article was read by anyone, let me assure them that PC SIMULA works fine
and thatthe problem reported is being sorted by the supplier. As a frequent user of
SIMULA on SUNs, PCs, VAXes and Macs, I have never found that they are "a mess". They
have the same sort and number of bugs as any othe compiler for any other language, I
guess. Maybe we should all remember that for those who are trying to make a living or
part of one from selling software this sort of blanket complaint is deeply injurious.
We had a rash of similar C++ complaints recently and I thought they had been squashed.

If in doubt ask the supplier.

If anyone is interested in graphics  from SIMULA I have some simple stuff that can
provide an OO windows/graphics interface to X Windows and which should port easily
to Windows and Macs. Free to serious users, as long as you tell me how you get on
with it and send me any "improvements" you make to it or ports you do.

Remember most software suppliers aren't billionaires, whatever Bill Gates may earn.

Rob Pooley
Computer Science, Edinburgh University and
EASE Ltd, 24 Clifford Road (N0 5), North Berwick, EH39 4PP, Scotland