HDTenEightyP/NetNews huggingface dataset:
From: santas@inf.ethz.ch (Philip Santas)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 18 Aug 92 22:57:39 GMT
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH


In article <PCG.92Aug18161744@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>On 17 Aug 92 04:00:24 GMT, doug@monet.ads.com (Doug Morgan) said:
>
>doug> O An example?  How about seeing how the new system would address a
>doug> question that pops up on this group every month or two.  The
>doug> question is always how to organize the inheritance of a mutable
>doug> square class instance with three slots and a mutable rectangle
>doug> class instance with four slots.

By making the former a subclass of the latter. 
If I remember correct, the problem was not actually if square should
be a subclass of rectangle, but if this is possible in C++ :-)

>doug> Now, how would this new system help clarify the notions of
>doug> abstract types (rectangle and square),
>
>In no way at all! That's a problem for algebrists to solve. What is the
>optimal conceptual orthogonal base for an algebra that encompasses both?
>It's not a problem for the language designer. The task of the latter is
>to provide clean, general notation to _describe_ such things.

Why not to _construct_ such things? What is the advantage of having
something _just_ described? (notice that by construction I do not
mean necessarily implementation, but definition of structures).

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
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M() versus M(O) notation
Date: Fri, 21 Aug 92 19:17:13 GMT
Organization: Object Systems

  [Please forgive my brief interjection, I haven't been following this
   discussion.]

In article <1992Aug21.025530.19949@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
>important design technique.  Abstract classes are more powerful than
>templates because you can do more than just fill in the missing 
>operations, you can also redefine the operations that are provided.
>Thus, the provided operations all become defaults that a new subclass
>can replace with a more efficient version.

Defaults can be specified with generics and templates.  Formal generic 
subprogram parameters with defaults don't even require function pointers.

bob
objsys@netcom.com

P.S.  I kind of like the idea of first-class type variables myself.
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 21 Aug 92 01:10:35 GMT
	<d!!n91k.objsys@netcom.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 19 Aug 92 01:13:34 GMT, objsys@netcom.com (Bob Hathaway) said:

objsys> [I'm afraid I've inadvertantly turned Piercarlo into a
objsys> gelatinous mass.  Either he's foriegn or has reading trouble.]

objsys> The notion of type and class is trivially understood from of the
objsys> referenced texts, anyone reading the material and not
objsys> understanding it is either a novice or incompetant (referring to
objsys> some workshop where they apparently couldn't understand this
objsys> trivial issue).

	%A Jens Palsberg
	%A Michael I. Schwartzback
	%T Three Discussions on Object-Oriented Typing
	%P 31-38
	%J OOPS Messenger
	%V 3
	%N 2
	%D APR 1992

objsys> I'm also dissappointed that you apparently punted on my
objsys> non-hierarchical question in the PS of my last reply to you; I
objsys> think the answer is trivial and you did seem to think the issue
objsys> was important, as I do.  C'mon, give it a try!-)

I don't have much time to waste with people that take the approach to
debate illustrated in the above lines, and that, most emphatically, are
not my colleagues.

Besides I am currently very busy and I have fallen substantially back in
my e-mail and news processing, and some of the subject matter under
discussion is not as easily trivialized as you seem to reckon (I have
been thinking over an article by Professor Johnson for ten days now, for
example), so I have chosen to concentrate for now on more immediate
subject matters.
--
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
Xref: sparky comp.object:3201 comp.software-eng:3202
From: masood@ee.rochester.edu (Taha Masood)
Newsgroups: comp.object,comp.software-eng
Subject: IDE OO-Tool Evaluation Request
Date: 13 Aug 92 22:36:27 GMT
Organization: Univ of Rochester, College of Engineering and Applied Science


 I would like to request an assessment of IDE 
object oriented Design tools. If there are users out there
who have been using these tools please e-mail me your assessment.
I would compile the list of all replies and post it to this newsgroup.




Taha

e-mail masood@ee.rochester.edu
or
masood.wbst311@xerox.com
Newsgroups: comp.object
From: aro@aber.ac.uk (Andrew Ormsby)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 21 Aug 92 17:05:05 GMT
	<d!!n91k.objsys@netcom.com>
Reply-To: aro@aber.ac.uk (Andrew Ormsby)
Organization: CS Dept, University College of Wales, Aberystwyth

In article <d!!n91k.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:

   [I'm afraid I've inadvertantly turned Piercarlo into a gelatinous mass.
   Either he's foriegn or has reading trouble.]

I shall refrain from commenting on the gelatinous state (or otherwise)
of Piercarlo (;-)), but I can confirm that he is foreign. So are you.
What's your problem?

--
Andy Ormsby, aro@aber.ac.uk
Newsgroups: comp.object
Subject: O.M(...) vs M(...), and is the Real World O-O?
Reply-To: bradcox@infoage.com (Brad Cox)
Organization: Information Age Consulting
From: bradcox@infoage.com (Brad Cox)
Date: Fri, 21 Aug 92 23:05:42 EST
X-Mailer: Fernmail 1.2b1

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

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.

The implications of this difference are *large*; easily large enough to
account for the length of this debate.

Brad Cox, Ph.D.
Information Age Consulting
703 968 8229 voice
703 968 8798 fax

New address:
Program on Social and Organizational Learning
George Mason University
Fairfax VA 22030
(703) 993-1142

---
Brad Cox, Ph.D.                (203) 868 9182 voice / (203) 868 0780 fax
Information Age Consulting     bradcox@infoage.com [or bradcox@aol.com (25kB max)]

After 24Aug92
    College of Arts and Sciences
    Program on Social and Organizational Learning
    George Mason University
    Fairfax VA 22030
    (703) 993 1142
Newsgroups: comp.object
From: graham@maths.su.oz.au (Graham Matthews)
Subject: Re: O.M() versus M(O) notation
Organization: School of Mathematics and Statistics, University of Sydney
Date: Mon, 17 Aug 1992 11:44:34 GMT

(Ralph Johnson) writes:
>First, I agree completely that it is a good idea to separate interface
>from implementation and from specification.  There are times when you
>want to be able to reuse one of them without reusing the other, and
>combining them in the way that all the popular object-oriented languages
>do makes it harder to reuse just the piece you need.  This results in
>tricks like overriding an operation to make it generate an error
>message, which Piercarlo complained about.  Separating interface from
>implementation seems to be the trend in the design of object-oriented 
>programming languages.  There are several research languages that follow 
>this path, though the only language I know about that is expected to be 
>widely used and that separates interface from implementation is the 
>object-oriented Cobol proposal.  I'd love to be told of languages that
>separate specification from implementation that I don't know about.
>
>Note that languages like Smalltalk have only implementation; they don't
>provide a separate interface or specification.  Only Eiffel provides
>any sort of specification (pre and post conditions and class invariants)
>in the language.

Could someone provide a concrete example of where seperating interface
and implementation buys one a whole lot, or where you want to inherit
part of an interface. I am not saying that it can't be done or isn't
useful, I am merely interested in an illustrative example.

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: irvine@ntmtv.UUCP (Chuck Irvine)
Subject: Re: Beginner's Question - CLOS
Organization: Northern Telecom Inc, Mountain View, CA
Date: Wed, 19 Aug 1992 20:38:46 GMT

CLOS is a work of art! It really is an advance in the object
oriented paradigm. A good high level reference is
"Object Oriented Programming in Common Lisp" by S. Keene.
For a complete reference try "Common Lisp the Language" 2nd 
edition by G. Steele. FYI

Chuck Irvine
Newsgroups: comp.object
From: br707@cleveland.Freenet.Edu (Mike L. Melamed)
Subject: Needed a sample
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Wed, 12 Aug 92 21:24:17 GMT


I have finished learning about OOP and can write a simple program but
I would really like to have a small example of all the cosepts
of Object Oriented Programming in TURBO PASCAL... I really lack a good
example..


Thank you very much...



Mike





--
From: objsys@netcom.com (Bob Hathaway)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 19 Aug 92 01:13:34 GMT
Organization: Object Systems

[I'm afraid I've inadvertantly turned Piercarlo into a gelatinous mass.
Either he's foriegn or has reading trouble.]

In article <PCG.92Aug18133356@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes:
>On 18 Aug 92 03:02:46 GMT, objsys@netcom.com (Bob Hathaway) said:
>objsys> Not really.  Types and type systems are clearly defined in
>objsys> almost all compiler texts (ASU), several modern languages
>objsys> (Emerald, Trellis/Owl),
>
>And all these definitions refer to *different* things. Too bad.

No, if you read them carefully you'll notice they are all consistent,
thats why I listed them!  I won't bother with the rest of you're
contentions in this posting, theres no substance.  The notion of type
and class is trivially understood from of the referenced texts,
anyone reading the material and not understanding it is either a
novice or incompetant (referring to some workshop where they apparently
couldn't understand this trivial issue).

I'm also dissappointed that you apparently punted on my non-hierarchical
question in the PS of my last reply to you; I think the answer is trivial
and you did seem to think the issue was important, as I do.  C'mon, give
it a try!-)

bob
objsys@netcom.com
Newsgroups: comp.object
From: chrisv@runx.oz.au (Chris Velevitch)
Subject: Re: What is Blackboard Architecture (was: OOPSLA Workshop on "Architecture Handbook")
Keywords: Blackboard
Organization: RUNX Un*x Timeshare.  Sydney, Australia.
Date: Wed, 19 Aug 92 02:40:10 GMT

In article <1992Aug14.213451.24521@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
>Architectures exist at different levels; for example we have overall
>architectures such as Model-View-Controller or Blackboard, and we have

What is Blackboard? Where can I find references on Blackboard?

>Bruce Anderson	bruce@hpcea.ce.hp.com
>(University of Essex, England, on sabbatical at Hewlett-Packard)
-- 
Chris Velevitch
Internet: chrisv@runxtsa.runx.oz.au
UUCP: ...!uunet!munnari!runxtsa.runx.oz.au!chrisv
Voice: +61 2 906 6100, Fax: +61 2 906 6069
Xref: sparky comp.object:3264 comp.lang.clos:673
From: richter@mcc.com (Charlie Richter)
Subject: Re: Type Conformance and Inheritance (was O.M() versus M(O) notation)
Organization: MCC, Austin, TX
Date: Thu, 20 Aug 1992 15:20:06 GMT

> All object-oriented texts justify a view
> based on the real world, try Booch OO Design or Rumbaugh et al OO Modeling
> and Design for some examples and for a jillian reasons why.

Just a tangential comment:  Not all methods take the view that *every*
object is a real-world entity.  For example, Jacobson et al. say:

   We thus do not believe that the best (most stable) systems are
   built by *only* using objects that correspond to real-life entities,
   something that many other object-oriented analysis and design
   techniques claim.
          - p. 135 of Jacobson et al., Object-Oriented Software Engineering,
                Addison-Wesley, 1992   [emphasis is theirs]

They introduce what they call "control objects" that do not correspond to
real-world entities, but rather are intended to encapsulate functions
that do not naturally reside in any particular real-world objects.
-- 
Charlie Richter   MCC   Austin, Texas
  uucp: richter@milano.uucp     arpa: richter@mcc.com
"The panic ... was not due to anything fundamentally weak in either business
   or finance.  It was confined to the market itself."   - WSJ, Oct. 31, 1929
Newsgroups: comp.object
From: steve@cahors (Steve.Hinde)
Newsgroups: comp.object
Subject: IWOOS '92 Paris
Summary: Request for details on IWOOS '92 ?
Keywords: IWOOS
Date: 11 Aug 92 19:26:56 GMT
Organization: Bull S.A.

Can anyone give me details on te forthcoming IWOOS '92 conference,
24-25 Sept, Paris, France, agenda, how to enroll etc.

Kind regards,

Steve


--
+----------------------------------+------------------------------------+
| Steve Hinde                      | Tel  : +33 76.39.77.36             |
| Software Architecture Group  	   | FAX  : +33 76.39.75.18             |
| Bull SA                          | TELEX: 980 648 F                   |
| 1, Rue de Provence - B.P. 208    | S.Hinde@frec.bull.fr		|
| 38432 Echirolles - CEDEX,FRANCE  | xopen.co.uk!s.hinde		|
+----------------------------------+------------------------------------+
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M() versus M(O) notation
Date: Tue, 18 Aug 92 03:26:47 GMT
Organization: Object Systems

In article <1992Aug16.212818.29943@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
>The purpose of an abstract class is NOT supposed to be to represent
>an interface.  An abstract class represents a skeleton for a class.
>It is a class that is to be used ONLY by subclassing.  A subclass
>designer creates a subclass by filling in the 'holes', i.e. by

I told you Piercarlo that people wouldn't like it if you tried to take
away their abstract classes!-)

bob
objsys@netcom.com
From: santas@inf.ethz.ch (Philip Santas)
Newsgroups: comp.object
Subject: Re: Type Conformance and Inheritance (was O.M() versus M(O) notation)
Date: 17 Aug 92 23:00:54 GMT
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH



In article <fb9mk5g.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
>pcg@aber.ac.uk (Piercarlo Grandi) writes:
>>Well, if by 'inheritance' you mean 'a fully general (including all
>>the "obvious" set operations like union, intersection, ...) way to
>>independently reuse separately defined interfaces, implementations,
>>assertions' then we are entirely agreed. My point precisely.
>
>Good.  Actually I believe the correct use of inheritance is to implement
>the is-a relation and don't believe that this relation precludes anything
>so far discussed or enforces unnecessary hierarchical restrictions (except
>as discussed above with classes for the latter).  The set operations sound
>interesting though: set union sounds like multiple inheritance.

You mean set _intersection_ does this, if one considers class as a set
of all possible (current and future) objects. If you consider it as
set of operations, then union could have been a good word
if you could test functions for equality...

Another problem is the is-a notion. Piercarlo made a good point, by 
not including this into the inheritance. If you really want to have 
an absolute is-a relationship, and strict classifications, then most 
(all?) of the current systems, do not fall in this category (just 
think of the pinguin-bird example).

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
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.object,comp.lang.clos
Subject: Re: Beginner's Question - CLOS
Date: 20 Aug 1992 16:06:25 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <DCMARTIN.92Aug19151550@fascet.msi.com> dcmartin@msi.com writes:
>In article <1992Aug19.213818.21709@tfs.com> eric@tfs.com (Eric Smith) writes:
>
>   But doesn't that make method dispatch very time consuming?  It seems like
>   it would involve searching for the method in tables, and that the amount
>   of time consumed would depend on how many methods were in those tables and
>   how many class arguments each method had.
>
>Yes, if you did things that way.  In fact, you can determine at compile time
>what the argument types are and then put in the appropriate call to the
>appropriate function.

That's not true in general, unless you use some implementation-dependent
mechanism to tell the compiler that the class named in a specializer or
type declaration will never have any subclasses, or that these subclasses
won't override the method.  If you don't do this, then an object of a
subclass may be provided, and it may have its own methods for the generic
functions.  Type declarations can be used to determine which methods
definitely *won't* be run automatically, but the compiler can't statically
determine the complete list of methods that *will* be run.

This problem is the reason for Dylan's freezing and sealing concepts.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.object
From: graham@maths.su.oz.au (Graham Matthews)
Newsgroups: comp.object,comp.lang.clos
Subject: Beginner's Question - CLOS
Date: 19 Aug 92 13:18:57 GMT
Article-I.D.: galois.graham.714230337
Organization: School of Mathematics and Statistics, University of Sydney

(Chris Dollin) writes:
>In the software reality, M can certainly be the doer; consider CLOS, for
>example, with generic functions rather than objects-that-know-how-to.

Not being overly familiar with CLOS I am intrigued by this comment
Chris. I am presently looking at ways in which Object-Orientedness
is present in languages with an eye to adding it to an existing language
I have written. Now what I know of OO comes mainly from using Eiffel - that
is one has a class which contains methods, one makes an instance of a
class using a constructors, and one invokes methods using the hotly
debated O.M notation. Oh yeah and there is a form of inheritance thrown
in here - thats how I understand things. This is the objects-that-know-
how-to flavour of OO I presume.

Now to CLOS. The above comment would suggest that CLOS does not do
things in the objects-that-know-how-to flavour. If this is so the
only sort of alternative I can think of (not knowing CLOS) is to
have objects that are defined by some sort of record structure, where
each slot can be a function. I presume that a function can take an
argument of type X or any sub-type of X. How is this subtyping specified.
(note: I appreciate that I am using sub-type in a very sloppy sense
here but I think it is obvious what I mean here). Is this indeed what 
CLOS does? If so how are sub-types specificied. I would be
interested in seeing a specification for say a stack in CLOS (any
takers out there). Assuming that this is indeed the approach taken
by CLOS what does it buy you? It would seem to me to be basically no
different to the other approach - the main difference being in the
fact that the Eiffel approach has method invocation based on one
argument. Outside of this what does the CLOS approach have by way of
advantages?

I don't intend to start a flame war here between Eiffel and its
adherents and the CLOS people. I am merely interested in why the two
different approaches are taken. I wish to understand the strenghts
and weakness of each before jumping in over my head.

Email is welcome

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: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: How FUNCTION be OPJECTS?
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
Date: Fri, 14 Aug 1992 14:30:52 GMT

In <STEVE.92Aug11165341@diana.Advansoft.COM> steve@Advansoft.COM (Steve Savitzky) writes:

>The time when you *really* need functions to be objects is when you
>need to pass a function as an operand (e.g. to a sort method) or keep
>it as part of some object's state (e.g. a graph widget).

>Languages like Smalltalk make life difficult by having two
>incompatible representations for functions used in this way: as a
>block or as the name of a method.

In Smalltalk the normal way of doing this is to pass blocks, method
names are uncommon.

There is an advantage to method names. The method "perform:" can be
considerably faster than "value". This is certainly true in
Smalltalk/V. I'm not sure if the optimization of simple blocks in
ObjectWorks succeeds in getting rid of this overhead or not.  I
implemented something that avoided the incompatability by defining
additional methods so that the two could be used interchangeably. I
actually used

   blockOrString applyTo: obj1 and: obj2 ...

although there's no reason you couldn't have implemented value,
value:value: etc. for strings or perform:, perform:with: etc for
Strings.

-- 
 Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x5783   Join
 Dept. of Mechanical and Aerospace Engineering                the
 Carleton University, Ottawa, Ontario, Canada, K1S 5B6        LPF

Xref: sparky comp.object:3259 comp.lang.clos:663