HDTenEightyP/NetNews huggingface dataset:
From: theo@rascal.UUCP (1472)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 20 Aug 92 07:52:10 GMT
Reply-To: theo@rascal.UUCP (T. Kramer 794-1472)
Organization: Rascal Systems

In article <1992Aug15.124149.28538@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
>
>I remember a short story (probably science fiction) in which there was
>a line like: "My name is Jonathon Marks.  The name of my name is
>Big Bill.  Call me Wally."  Also, his gun had a name, the name of
>his gun had a name, and he called his gun something else.  This
>seems to illustrate the problem well.  Does anybody remember the
>author and title of this short story?
>

I do not know the author of the above, but it probably has it's roots
in "Alice in wonderland" by Lewis Carrol.

My opinion on the subject line =
|     |              |
| +---+              |
| | +----------------+
| | |
v v v
O.M(x)

+---------------------------+------------------------------------------------+
|  theo@rascal.UUCP         | Show me your object and I will show you mine   |
+---------------------------+------------------------------------------------+
Newsgroups: comp.object
From: acmtsv@gsusgi2.gsu.edu (Thomas Scott Vaughn)
Subject: Research Project
Organization: Georgia State University
Date: Wed, 12 Aug 1992 22:51:43 GMT


I'm doing a research project on the use of OOP by the "Real" world
mainly buisinesses.  Any input about what you do with OOP and how you
make it work would be welcome.  I'm particularly interested in your opinions 
about the shortcomings of today's OO languages and what should be done to
make OOP better.  Especially interested in comments on C++.  Example code
welcome!

Thanks
-- 
					Thomas S. Vaughn
					Atlanta, GA
					acmtsv@gsusgi2.gsu.edu
From: wltam@cucs17.cs.cuhk.hk
Newsgroups: comp.object
Subject: Request for data on OO development ?
Date: 13 Aug 92 09:14:22 GMT
Organization: Dept of Computer Sci, CUHK

Hello all, 8-)

	Anyone on this newsgroup knows of any data available for the complexity

of Object-oriented applications (measured in Chidamber & Kemerer's proposed

metrics for OO ....or any other S/W metrics) together with the approximated

developement cost (either measured in $ or just man-month(M-M) or just in

vague term like 'high', 'medium' or 'low') ? 

	I'm doing a survey on OO project management. And I would greatly

appreciate if anyone on this network can give me any pointer to any related

inf. 

Thanks in advance ! 8-)


Best Regard.,
Vincent Tam (MPhil. of CUHK)
Newsgroups: comp.object
From: thinman@netcom.com (Technically Sweet)
Subject: Re: A Graph Theory Newsgroup, Perhaps?
Date: Wed, 19 Aug 92 01:59:31 GMT
Organization: International Foundation for Internal Freedom

orpheus@reed.edu (P. Hawthorne) writes:


>  Graph theory is at the heart of so many fields that it is somewhat
>obscured by its own versatility.

>  I feel that there ought to be a graph theoretic newsgroup, if only for
>the insights that such a multidisciplinary newsgroup could offer.

>  I'd be interested in hearing from others, to see if a more formal
>approach to creating such a newsgroup is warranted.


There is already a comp.theory.  I don't follow it.

If you're interested in computing with graph theory,
get the LEDA toolkit from sbsvax.cs.uni-sb.de:/pub/LEDA/LEDA...tar.Z.
It's in C++ and pretty spiffy.  Has lots of graph theoretical
and other operations in various class libraries.
-- 

Lance Norskog

Data is not information is not knowledge is not wisdom.
From: santas@inf.ethz.ch (Philip Santas)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 17 Aug 92 22:43:37 GMT
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH


In article <1992Aug16.212818.29943@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
>
>>johnson> An abstract class is much more than just an interface
>>johnson> specification.  It also includes part of the implementation of
>>johnson> the class, but it has some 'holes' in it that subclasses must
>>johnson> fill in.  It is really a reusable design for subclasses, not an
>>johnson> interface specification.  Of course, in languages without
>>johnson> separate interface specifications, people use abstract classes
>>johnson> to make a separate entity in their program that is just
>>johnson> interface.
>
>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
>"fleshing out" the skeleton.  It is true that C++ programmers will
>create a class that is only interface, with no implementation at all,
>but that is not the real purpose of an abstract class.  An abstract
>class is implementation, not just interface.

I am sorry, but this clarification, does not make things clearer to me.
If the abstract class "is NOT supposed to be to represent interface", 
then how can it be "not just interface"? Does it represent interface after all?
I think that your answer is important here since it seems to represent
the whole (almost the whole) OO community in this discussion..

Concerning skeleton: is this including both interface and implementation?
(given Piercarlo's definitions, with which I do not completely agree,
but for the moment I do not have ready to present something less complicated)

>An abstract class defines some "abstract" or "deferred" methods
>whose interface is defined, but whose implementation is not.
>It also defines some "template" methods that are defined in terms
>of the abstract methods.  Subclasses must provide an implementation
>of each of the abstract methods, and then they can use the template
>methods that they inherit.  This is a very important and common
>design technique in object-oriented systems.  It would be just as
>useful if languages separated interface from implementations.

If the abstract class _is_ implementation, then why _must_ the subclasses
redefine the implementation? One has to choose what implemnetation is
inherited where in the most general way.

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: sbate@atl.ge.com (Stephen Bate)
Newsgroups: comp.object
Subject: Re: OMTool
Date: 13 Aug 92 18:45:00 GMT
Reply-To: sbate@atl.ge.com
Organization: GE Advanced Technology Laboratories

In article <BUTLER.92Aug11173511@umbria.aaii.oz.au> butler@aaii.oz.au (Jim Butler) writes:

> Does anybody have a contact for OMTool? Thanks.

OMTool is being distributed by GE's Advanced Concept Center.

GE Advanced Concepts Center
P.O. Box 1561
640 Freedom Business Center
King of Prussia, PA 19406 USA
Telephone (215) 992-6200


--
Stephen Bate                |
GE Advanced Technology Labs | Internet: sbate@atl.ge.com
300 Route 38, Bldg. 145-2   | Voice: 609-866-6603
Moorestown, NJ 08057        | Fax:   609-866-6397
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Tue, 18 Aug 1992 10:04:34 GMT
Subject: Re: Re: Type Conformance and Inheritance (was O.M() versus M(O) notation)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.object

In article ... Bob Hathaway <objsys@netcom.com> writes:

   No it is not.  There is nothing symmetrical about pushing an element onto
   a stack since the two objects are not equal gramatically.  O.M ...

I don't see what the grammatical status of an object has to do with anything.
Surely we're discussing *meaning*, not *notation*, here, and PGs point is
exactly that the asymmetry of the O.M(...) notation *encourages* a
corresponding but irrelevant semantic asymmetry.

   is imperative (with an IE,) showing clearly the Object (O) to be the
   receiver (or doer) of the command (M) and parameters to be objects.

I think it's M that's the "doer" and O,(...) are the parameters.

   A stack has a push "action" so the stack is the doer of the action and
   making this explicit should help.  

But this is just one interpretation, right? Stacks don't "have" push actions as
a matter of Natural Law; it's just one way of carving the computational cake.
We can just as well say that pushes "have" stack variants.

Now, in the case of stacks and pushes, the stack *changes* [assuming we're in
an imperative context; in something like Haskell or Axis, the push just gets
you a new stack, and nothing changes, not ever, not even a bit.]. You could
chose to indetify the "doer" with the thing subject to change ("objects know
how to do things to themselves"). An odd model, this, when normally one expects
the doer to be the one *not* suffering the effect!

Also, if several objects (parameters) are affected, this criterion breaks down.
What about moving an object from one stack to another? Why should the move
"message" be sent to one of them, rather than the other? You may argue that
"move" isn't a real primitive on stacks, but who are you to argue with my
analysis of a problem domain? [Perhaps I shouldn't call them "stacks", but the
point remains.]

   If this isn't so clear, then go imperative without an explicit receiver of
   M. 

By which I presume mean ``try the symmetic notation''.

   If it is, you're obfuscating the reciever which will be to the detriment of
   understanding.  

Well, the second part follows from the first, because of the meaning of
``obfuscation'', but I don't think it's true that one is obf. the receiver,
because I think the receiver is the message [at least for the purposes of this
note]. 

   Also, whats with this "only overloading on the first parameter" stuff?  
   Have you heard of multi-methods or more simply "dynamic method selection"? 

Surely this is the point of PGs postings; given multi-methods, why on earth
should the invocation syntax specially distinguish one object out of the
several supplied?

   I can't make sense of it.

Of multi-methods or of the discussion so far?

Remember, The Real World Is Not Object-Oriented.




--

Regards,                    | "I always prefered Sherlock Holmes to Dan Dare"
Kers.                       | Nathan Spring, in BBC2's _Star Cops_.
Newsgroups: comp.object
From: jbone@splat.dell.com (Jeff Bone)
Newsgroups: comp.object
Subject: Re: A Graph Theory Newsgroup, Perhaps?
Date: 20 Aug 92 14:21:54 GMT
Article-I.D.: splat.jbone.714320514
Organization: Dell Computer Co

thinman@netcom.com (Technically Sweet) writes:
>
>If you're interested in computing with graph theory,
>get the LEDA toolkit from sbsvax.cs.uni-sb.de:/pub/LEDA/LEDA...tar.Z.
>It's in C++ and pretty spiffy.  Has lots of graph theoretical
>and other operations in various class libraries.
> 

Well, if you've tried to suck this puppy over the Big Pond you'll have
noticed that (a) it takes forever and (b) the connection never stays
up long enough to get the whole thing (at least from my corner of the
Net).  AND archie doesn't reveal any domestic sites.

Well...  just by accident I stumbled across an older copy of this thing
on xcf.berkeley.edu:/src/programming/c++/LEDA-2.2.0.tar.Z...  NOTE that
this isn't the newest version (the German site has a 2.2.2), but I guess
that's better than nothing.

FYI, use this information at your own risk. ;)


jb


PS - if anybody successfully retrieves the version from across the water,
could you stick it up for ftp somewhere domestically and post the location
to this group?  Thanks....




--
-- Jeff Bone ------------------------------------------------------------
      "Imagination is more important than knowledge."  - A. Einstein
------------------------------------------------------- jbone@dell.com --
                                                                       --
From: tmhoff@oogoody.Corp.Sun.COM (Todd Hoff)
Newsgroups: comp.object
Subject: Re: A Graph Theory Newsgroup, Perhaps?
Date: 20 Aug 92 19:46:04 GMT
Reply-To: tmhoff@oogoody.Corp.Sun.COM
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: oogoody.corp.sun.com

>Well, if you've tried to suck this puppy over the Big Pond you'll have
>noticed that (a) it takes forever and (b) the connection never stays
>up long enough to get the whole thing (at least from my corner of the
>Net).  AND archie doesn't reveal any domestic sites.

I had a lot of trouble connecting to germany, but site watserv1.waterloo.edu   (129.97.129.140) has a reliable connection and the most recent version.
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M() versus M(O) notation
Date: Fri, 21 Aug 92 19:32:41 GMT
Organization: Object Systems

In article <ARO.92Aug21170505@sibyl.aber.ac.uk> aro@aber.ac.uk (Andrew Ormsby) writes:
>In article <d!!n91k.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
>
>   [I'm afraid I'v inadvertantly turned Piercarlo into a gelatinous mass.
>   Either he's foreign 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?

I apologize for making such a stupid and meaningless comment.  Piercarlo
and I were discussing the hierarchical vs. graph question, I was on
the graph side (as I thought he was) and he gave some meaningless example.
After providing some true graphical examples and pointing out my graph
orientation of several years, he ignored my comments and then claimed I
was advocating the hierarchical approach!  Maybe he was referring to
someone else.  He then ignored several consistent and clear references
for my terminology (slighting several distinguished individuals on the way,
such as Booch and W. Kim) without providing any references himself, and
then claimed *I* had made up my terms!  Oh well.  He reminded me of someone
I know that can hardly speak English and blabbers alot.  Happens to the
best of us in the heat of battle, I guess.

Sorry if I upset anyone, I genuinely didn't mean to.

bob
objsys@netcom.com
Newsgroups: comp.object,comp.lang.eiffel
From: guna@cc.gatech.edu (L. Gunaseelan)
Subject: Re: Persistence: Pragmatic and Abstract
Keywords: persistence think class oop
Organization: College of Computing, Georgia Tech
Date: Thu, 13 Aug 1992 16:39:17 GMT

In article <1992Aug9.164259.23429@reed.edu> chaffee@reed.edu (Alex Chaffee) writes:
>I have an object-oriented design question. This is my first big OOP project,
>and I'm fumbling through it the best I can. The project involves two
>programs, a client and a server, and they need to send data structures back
>and forth across a local network. To accomplish this, I imagine that each
>data structure will be an object that can "wrap itself up" into a stream of
>bytes (actually into a Macintosh handle), and then "unwrap" such a handle
>and change its state to match the other object's. These handles will be sent
>across the wire and "unwrapped" at the other end.  In other words, the
>problem is one of persistence.
>
>What's the problem? Since I'm using the Think Class Library, I have a class
>hierarchy available to me which implements things like arrays, which I want
>to use. Unfortunately, this hierarchy doesn't allow persistence. I am left
>with several options, and I can't decide between them.
>

The point I am making here may not be of direct use to solve
your problem. However, I would like to highlight that the problem is
one of language design than programming. 

In C language, when you see a pointer you are not sure of what
it points to (with typecasting and so on); when you have list
you don't know how long it is, it requires traversing the list and
packing the elements. The XDR (external data representation) support
that is part of the Sun RPC (also OSF/DCE, I guess) allows the 
programmer to do exactly that.

In contrast, consider the Eiffel programming language. In Eiffel,
there are no pointers and it uniformly uses reference semantics - 
a reference always points to an object of specific type.
Since objects are completely typed,  the language design
allows writing routines that can automatically pack and unpack
objects, without out bothering the programmer to write class-specific
marshalling and unmarshalling routines. This is the basis of the 
STORABLE class in the Eiffel implementation. 

In fact, we have a distributed implementation of Eiffel that runs
on the Clouds distributed operating system, where any graph structure
of fine-grained Eiffel objects can be passed during remote
invocations (RPCs) by deep copying the graph into a string of bytes. 
The programmer makes RPC calls as he would in a procedural language, 
and the run-time system handles marshalling and unmarshalling 
automatically, using the routines available in the ISE's run-time
library.  Again, the programmer never needs to write class-specific
packing/unpacking routines.

Guna..
Newsgroups: comp.object
From: pat@bnrmtl.bnr.ca (Patrick Smith)
Subject: Re: O.M() versus M(O) notation
Reply-To: patrick@bnr.ca
Organization: Bell Northern Research
Date: Fri, 21 Aug 92 16:11:28 GMT

In article <456@rascal.UUCP>, theo@rascal.UUCP (1472) writes:
|In article <1992Aug15.124149.28538@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
|>I remember a short story (probably science fiction) in which there was
|>a line like: "My name is Jonathon Marks.  The name of my name is
|>Big Bill.  Call me Wally."  Also, his gun had a name, the name of
|>his gun had a name, and he called his gun something else.  This
|>seems to illustrate the problem well.  Does anybody remember the
|>author and title of this short story?
|
|I do not know the author of the above, but it probably has it's roots
|in "Alice in wonderland" by Lewis Carrol.

If memory serves me correctly, a speech along similar to the above
was uttered by the White Knight.  Which would place it in "Alice
Through the Looking-Glass" (also by Lewis Carroll = Charles
Dodgson, of course).

-- 
Patrick Smith            preferred: larry.mcrcim.mcgill.edu!bnrmtl!pat
Bell-Northern Research   next best: patrick@bnr.ca
(514) 765-7914
Xref: sparky comp.object:3282 comp.lang.clos:685
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object,comp.lang.clos
Subject: Re: Beginner's Question - CLOS
Date: 21 Aug 92 00:56:41 GMT
	<1992Aug19.213818.21709@tfs.com>
	<DCMARTIN.92Aug19151550@fascet.msi.com>
	<170fu1INNmfh@early-bird.think.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 20 Aug 92 16:06:25 GMT, barmar@think.com (Barry Margolin) said:
NNTP-Posting-Host: telecaster.think.com

barmar> dcmartin@msi.com writes:

dcmartin> (Eric Smith) writes:

Smith> But doesn't that make method dispatch very time consuming?  It
Smith> seems like it would involve searching for the method in tables,
Smith> and that the amount of time consumed would depend on how many
Smith> methods were in those tables and how many class arguments each
Smith> method had.

dcmartin> Yes, if you did things that way.  In fact, you can determine
dcmartin> at compile time what the argument types are and then put in
dcmartin> the appropriate call to the appropriate function.

barmar> That's not true in general, unless you use some
barmar> implementation-dependent mechanism to tell the compiler that the
barmar> class named in a specializer or type declaration will never have
barmar> any subclasses, or that these subclasses won't override the
barmar> method.

Fully agreed, but this information can be easily deduced by a 'system
builder', i.e. an intelligent linker, like Eiffel has (for more or less
this reason). A system builder can create a complete list of all the
types in an application (unless they can be defined at run time), and
can do such overload resolution at system building time, statically. I
think a 'system building' tool is something that is quite useful in
general, especially if it can be used more or less incrementally.

barmar> If you don't do this, then an object of a subclass may be
barmar> provided, and [ ... ]

... overloading cannot be assumed to be statically bounded.
--
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
From: "Ronald C. Schultz" <p00058@mail.psi.net>
Subject: Methodology Comparisons
Organization: Berard Software Engineering, Inc.
Date: Wed, 12 Aug 1992 15:43:44 GMT
X-Mailer: PSILink (3.01)

I am in the process of completing a methodology comparison of the 
following object-oriented methods:

	Booch
	Rumbaugh
	Martin/Odell
	Wirfs-Brock
	Embley/Kurtz
	Shlaer/Mellor
	Berard
	Colbert

The comparison involves evaluating the following components for each method:

	Object-Oriented Concepts and Constructs Supported 
	Models and Model Notations
	Process and Process Definition
	Pragmatics
	Support for Software Engineering Goals and Principles
	A Roadmap for Corporate Assessments

My question is, does anyone have personal experience with the use of any 
of these methods in their projects, and would they be willing to discuss 
their thoughts, concerns, and overall outlook for the method (either on 
or off the record)?  

Any assistance would be most appreciated.

------------------------------------------------------------------------------
Ron Schultz 
Berard Software Engineering, Inc.
Columbus, Ohio Office                   Headquarters
5634 Claire Court                       101 Lakeforest Blvd.
Dublin, Ohio 43017-2440                 Gaithersburg, Md.  20877
(614) 798-0295 Phone                    (301) 417-9884 Phone
(614) 798-0296 FAX                      (301) 417-0021 FAX
ron@bse.com                             info@bse.com
------------------------------------------------------------------------------		
Newsgroups: comp.object
From: bindu@meaddata.com (Bindu Rao)
Subject: Need Info on OODBMS, ObjectStore vs. Objectivity
Keywords: Compare/ Contrast
Organization: Mead Data Central, Dayton OH
Date: Mon, 17 Aug 1992 15:51:31 GMT
Distribution: usa

Hi,
		I would like to obtain (first hand) info on the pros and
cons of using the following two commercial OODBMS:
1) ObjectStore
2) Objectivity

		Please email your input to bindu@meaddata.com

If you could provide any additional info, please feel free to send
them to me.

I have read the JOOP aarticle comparing OODBMS (for Engineering) but
it has not included Objectivity in its survey/evaluation.

The application is going to be rather large, with complex objects (and
composite objects).   It is aalso going to be "distributed" one.

Thanks in advaance.

bindu rama rao

PS: This is for my own research. My employer(s) are not responsible
for my actions. STD DISCLAIMERS APPLY

Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M() versus M(O) notation
Date: Tue, 18 Aug 92 03:06:31 GMT
Organization: Object Systems

In article <1992Aug15.215315.29866@sei.cmu.edu>, goodsenj@ajpo.sei.cmu.edu (John Goodsen) writes:
>> Bertrand Meyer is probably the chief opponent to this
>>view.  He says that one of the chief advantages of OOP is that it
>>*combines* interfaces with code, and that people who try to seperate
>>them are making a mistake.  Thus, it would be a mistake to think that
>>there is a concensus on this issue.
>
>Could you point us to where BM has stated this?  I'm finding
>it hard to believe that a sane person would make such a claim,
>and assuming sane people have made this claim, I'm uinterested to 
>understand the reasoning behind it....

I agree.  Class-based typing forms a very rigid structure in which every
object or class must inherit from the same class or else.  This may be
fine for trivial formal systems or in systems which do not change very
often; if you want it to match then inherit from it.  But more flexible
systems require a looser coupling for greater power and distributed systems
do not want the "inherit from *my* class or else" requirement since such a
requirement is unreasonable in any context where looser coupling is desired.

bob
objsys@netcom.com