HDTenEightyP/NetNews huggingface dataset:
From: jc@ri.cadre.com (Joe Cascio)
Newsgroups: comp.object
Subject: Re: OO & transaction handling systems
Date: 21 Dec 92 16:15:44 GMT
Article-I.D.: fripp.1992Dec21.161544.22621
Reply-To: jc@ri.cadre.com
Organization: Cadre Technologies Inc., Providence, RI

I don't have ready answers for all your questions, but
here are some...

>Currently we program in C & Oracle on a Pyramid MIS. The thing that 
>attracts me to an object way of doing things is that we have a large 
>number of types of transactions. There are also many types of 
>customers each of which have different functions associated with them. 
>
>'Sounds object-like, doesn't it? 

Sure does. Something you might run into is the
"cross-product" problem.  In your case this is
types_of_customers vs. types_of_transaction.  This typcially
results in a large number of possible combinations, not all
of which are unique.  Beware of trying to solve this all with
inheritance!!

This particular problem may be better solved with a third set
of classes that treat the combinations of transactions vs.
customers, and use instances of those classes.  Try to keep
any knowledge of customer types out of the transactions, and
vice versa.  Let this third "owner" class worry about the
cross-product.  If you're really compelled to use
inheritance, you could create "mix-ins" with multiple
inheritance that let you combine the attributes of the
appropriate sub-types.

>3) Are there any products that can help with storage / access
>   considerations? 
>

There are several OO database systems (e.g., Object Design)
available now that map the objects in memory directly to disk
and back, so you don't have to go through the conversion
process.

>4) It is said that OO systems don't necessarily have performance problems.
>   Is that true for OO systems as they grow in size? The size and 
>   complexity were exactly why one chooses a relational DB. OO may help 
>   me with the complexity, but can handle the amount of data? Recall 
>   5 years ago relational DB were said to have performance problems in 
>   this regard.
>

I can only comment on C++ here.  A well-designed C++
implementation has no inherent performance penalites over C.
The problem is the "well-designed" qualification.  New C++
users are prone to mis-using inheritance and virtual
functions, and ignoring really important aspects, which are
encapsulation, decoupling, and cohesion.  This can cause the
implementation to become overly complex or convoluted, which,
of course, leads to inefficiency.


---
==============================================================
* Joe Cascio                u----wm-
* Cadre Technologies Inc.        /\
* 222 Richmond St.              0_/  "$@@#!$#@$^&"
* Providence, RI 02903 USA       \
* phone: 401-351-5950             |     . .
* FAX  : 401-455-6803            /|   .    .   . .
* email: jc@cadre.com           / | .       . .   . . .
                               ^  ^          .     .   . ....
==============================================================
Newsgroups: comp.object
From: dave@alex.uchicago.edu (Dave Griffith)
Subject: Re: Equality
Organization: University of Chicago
Date: Tue, 22 Dec 1992 18:38:03 GMT

In article <BzoAD8.By6@newsflash.concordia.ca> grogono@cs.concordia.ca (Peter Grogono) writes:
>In article <1992Dec21.184405.2215@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:
>> .......
>>1) Equality should be reflexive.  
>>	I thought this was obvious, but IEEE754 may provide a counterexample.
>>
>>2) Equality should be symettric.
>>3) Equality should be transitive.
>>4) Substitution of equals for equals should give equals.
>>5) If two objects are equal at one point in program execution, they should be
>>     equal at all points. 
>>6) Assignment should respect equality.   (Assuming no side-effects, after 
>>   executing x:=a; it should be true that x=a.
>>7) If your parameter passing model is based on assignment, 6) should hold 
>>   mutatis mutandi.
>>8) If two objects are equal, they should be behaviourally indistinguishable. 
>>   The converse need not hold, but often will.
>>9) Two sets A,B are equal iff  for_all(x:A)there_exists(y:B) such y=x, and
>>   vice versa.
>>
>>Given mutable objects, identity was the only practical definition I found
>>which would  support all of the above.  However, identity is not a practical 
>>equality definition for all objects we wish to program with (vis, integers). 
>>In these cases, if immutability holds, users may be able to define equality
>>in ways which satisfy the above, and there are good reasons to let them try. 
>
>I do not see how "identity" supports #9. In principle, A=B, where A and
>B are sets, should mean that A and B have the same members, even if the
>representations of A and B are distinct in memory and may be different
>data structures. I do not see how an equality test of this kind can be
>built-in to a language, and this was my reason for saying that equality
>must be user-defined in general.
>
>Peter

Arrgh, another case of typing before thinking on my part.  I was thinking
in terms of relations and trying to come up with a way of expressing what I 
need.  I failed. For all of the above to hold for set objects, they must be 
immutable anyway (#5 and #8, as well as the basic mathematical idea of set), 
and I've never expressed any disagreement with user-defined equality for 
immutable objects.  If you want to test mutable "sets" to see whether they 
have the same members, but I'm not sure with calling such a test equality,
unless equality is just another binary predicate.


-- 
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       dave@alex.bsd.uchicago.edu
A man's best friend is his dogma.
From: lou@cs.rutgers.edu (Lou Steinberg)
Newsgroups: comp.object
Subject: Re: A Pre-Release FAQ
Date: 30 Dec 92 17:50:16 GMT
	<1992Dec30.012400.4233@netcom.com>
Reply-To: lou@cs.rutgers.edu
Organization: Computer Science Dept., Rutgers University, New Brunswick, NJ
	08903
In-reply-to: objsys@netcom.com's message of 30 Dec 92 01:24:00 GMT

In article <1992Dec30.012400.4233@netcom.com> objsys@netcom.com (Bob Hathaway) writes:

   In article <PCG.92Dec29203617@decb.aber.ac.uk> (Piercarlo Grandi) writes:
   >Gripe about definition of an object.

   Your points are well taken.  As pointed out by the PRE-DRAFT status
   of the FAQ, I am looking for feedback and expected it to be difficult
   to satisfy everyone, at least at first.  

While I understand your objection to the tone of Piercarlo's post, I
think you may be missing an important point.  If you look at other
groups' FAQ posts, you will find that they focus on objective
information (where can find free implementations of X, what are common
bugs in Y, what are good books on Z...).  More philosophical /
perspective issues like "what is an object" are pretty much immune to
concensus.  It is not simply "difficult to satisfy everyone at first",
it is impossible to satisfy everyone, period, because people have
flatly irreconcilable ideas.

Furthermore, an FAQ is (as the name implies) meant to answer frequently
asked questions.  It's goal is to save time and net bandwidth by 
providing answers to questions that otherwise would get asked on the
newsgroup.  The questions you answer don't seem like the kind of thing
I've been seeing people ask here.  (Although people *have* asked "what
is a good book to read as an introduction to objects." and that is
the kind of thing an FAQ usually answers.)

I suggest that you go through, or at least think back on, the last N
months of messages and find what questions really are (a) frequently
asked and (b) amenable to a concensus answer.
--
					Lou Steinberg

uucp:   {pretty much any major site}!rutgers!aramis.rutgers.edu!lou 
internet:   lou@cs.rutgers.edu
Newsgroups: comp.object
From: jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Date: 21 Dec 92 16:55:37 GMT
    <1992Dec16.175126.14968@midway.uchicago.edu> 
    <1992Dec17.163916.25512@kei.is.s.u-tokyo.ac.jp> 
    <1992Dec18.152823.888@midway.uchicago.edu> <knight.724801566@cunews>
Reply-To: jeff@is.s.u-tokyo.ac.jp
Organization: University of Tokyo / Object Technology International

In article <knight.724801566@cunews> knight@mrco.carleton.ca (Alan Knight) writes:

 >>In article <1992Dec17.163916.25512@kei.is.s.u-tokyo.ac.jp> jeff@is.s.u-tokyo.ac.jp writes:
 >>"Everything is an object", even such IMHO obvious non-objects like control
 >>structures.  Of course you can map everything to objects, I just see few 
 >>good reasons to do so.  

Yikes!  Either I've found some particularly good drugs or I didn't say
that.  Wonder which?

In article <knight.724801566@cunews> knight@mrco.carleton.ca (Alan Knight) writes:

 >I wish I were writing C++ code to interface Fortran and Cobol.

Personally, I think I was misquoted.  How 'bout you Alan? :-)

--
--
ato de, |m        -- Santa or Satan?  Think about it.
Newsgroups: comp.object
From: bran@helix.ObjecTime.on.ca (Bran Selic)
Subject: Re: A little glossary for objects
Reply-To: bran@ObjecTime.on.ca (Bran Selic)
Organization: ObjecTime Limited
Distribution: bnr
Date: Thu, 24 Dec 92 14:34:38 GMT

In article <1992Dec23.151238.3419@Informatik.TU-Muenchen.DE>, rumpe@Informatik.TU-Muenchen.DE (Bernhard Rumpe) writes:
|> 
|> 
|> Little glossary of object oriented software developement
|> ========================================================
|> 
|> This paper is one result of a workshop over software development
|> of three partners from software industry and universities. The glossary
|> is a mixture of different views: a practical and a formal one, according
|> to the backgrounds of the partners.
|> 
|> This glossary aims at giving small, rather formal definitions of object
|> oriented notions. The definitions are neither exact mathematic definitions
|> nor do they correspond exactly to the definitions used in the area of
|> algebraic specifications. We do not claim to cover the whole area of
|> object orientation with our definitions (but we tried to cover a large part).
|> 
|> So what do you think of the following definitions?
|> 

One thing that strikes me whenever people describe the object paradigm is
that defining what an "object" is, is only half the story. What is often
missing, in my view, is a definition of what I think is the primary aspect 
of the object paradigm: what an object-oriented "system" is.

(An informal definition: an object-oriented system is a network of
co-operating objects.)

The significance of this is that the definition of an object should be
driven from this "deductive" system-centric perspective rather than from
an "inductive" or, object-centric, view. After all, an object
(e.g., a stack) by itself is not very useful just like a brick by itself
is not useful. To carry this analogy further, we seem to be focusing
too much on the technology of bricks at the expense of developing an
understanding of architectures. 

There are a few exceptions too this, the work of Ralph Johnson and Ray Buhr
come to mind. Also, there is the ROOM methodology which recursively 
encapsulates an object-oriented system withinin a higher-level object (etc.)
allowing in this way entire architectures to be subclassed and reused as
components. Simple and effective as it seems, this idea has yet to be
widely accepted by the object community which in the best tradition of
academia looks for elegant solutions while ignoring the problems.

(This is not meant as a comment on the glossary that prompted this article;
I rather liked the glossary.)
-- 
*------------------------------------------------------------*
* Bran Selic                 |  phone: (613) 591-3435        *
* Vice President R&D         |  fax: (613) 591-3784          *
* ObjecTime Limited          |  e-mail: bran@objectime.on.ca *
* 340 March Road             |                               *
* Kanata, Ontario, CANADA    |                               *
* K2K 2E4                    |                               *
*------------------------------------------------------------*
From: mat@mole-end.matawan.nj.us
Subject: Re: A little glossary for objects
Summary: I correct myself ...
Organization: :
Date: Sun, 27 Dec 1992 21:04:36 GMT

I inadvertently chopped out two lines from my followup ...

In article <1992Dec27.014406.26583@mole-end.matawan.nj.us>, mat@mole-end.matawan.nj.us writes:
> In article <1992Dec23.151238.3419@Informatik.TU-Muenchen.DE>, rumpe@Informatik.TU-Muenchen.DE (Bernhard Rumpe) writes:
  
>> VALUE
>> 
>> A value is a value is a value.

> Forgive me for smiling.  In my forthcoming C++ book, I found myself forced
> to write something like this:
> 
> 	``A value is harder to define, but we usually know it when
>  

	``A value is harder to define, but we usually know it when
	we see it--in fact a value is what we see when we look at an
	object or an expression.''


						``You would know him if
						  you saw him, for his eyes
						  are sunken in.''--T.S.Eliot
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: A Pre-Release FAQ
Organization: Object Systems
Date: Wed, 30 Dec 1992 01:24:00 GMT

In article <PCG.92Dec29203617@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>Gripe about definition of an object.

Your points are well taken.  As pointed out by the PRE-DRAFT status
of the FAQ, I am looking for feedback and expected it to be difficult
to satisfy everyone, at least at first.  Fortunately, most of the comments
have been favorable and constructive, so lets try to keep it that way,
Ok piercarlo?  I'm the first to admit there's plenty to clean up and
I (as well as others) have already identified a number of areas in need
of improvement and lots of changes have already been made.

I'm editing away and will try to improve the FAQ's definitions, clear up
misprints and oversights, include suggestions and try to gear the FAQ more
towards what is typically asked.  Part of why I hurried out the FAQ was to
force something to be written and commented on, so at least there's
something to shake fingers at and plenty of posters shake them;-)

I'll try to have another PRE-DRAFT release out after the holidays, so keep
those suggestions coming.

Happy New Years!
bob
objsys@netcom.com
From: ll0x+@andrew.cmu.edu (Lawrence Linn)
Newsgroups: comp.object
Subject: Choreographer by GUIdance Tech.
Date: 22 Dec 92 09:07:47 GMT
Organization: Masters student, Industrial Administration - 3rd Yr. Opt., Carnegie Mellon, Pittsburgh, PA

Our company has just seen a demonstartion of Choreographer by GUIdance
Tech. and I was wondering if anyone in the group has any comments on the
product???
Newsgroups: comp.object
From: grogono@cs.concordia.ca (Peter Grogono)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Date: 21 Dec 92 21:10:06 GMT
Organization: Computer Science, Concordia University, Montreal, Quebec

In article <BzIFGp.K7@cs.uiuc.edu> johnson@cs.uiuc.edu (Ralph Johnson) writes:
>The difference between an "object" and a "value" seems to be that for
>a value, equality can be implemented by bit comparison of the things,
>while objects can only use identity of addresses in memory or else
>require a user-supplied function.  Isn't this just a result of immutability?

This is misleading because equality is (almost) orthogonal to the
object/value distinction.  Graphs, with edges represented by pointers,
may be values, but you would not want to compare them bit-by-bit in
an equality test, because "equality" in this case should mean
"isomorphic" for most applications.

I agree that objects are "equal" (actually "identical") if they have
the same address, and that this is often a useful test.

The underlying problem is the difference between intensions and
extensions. As a general rule, we compute with intensions but we
want to compare extensions. The strings "2+2" and "1+3" have the
same extensional value, under a suitable interpretation, but are not
equal strings. If we convert them to the integers 4 and 4, we achieve
equality, but that is mere good fortune, because we are
still working with intensions (or representations). The whole point
of semantic theories is to show that we can obtain correct
extensional results while working with intensions.

IMHO, there is no suitable default for equality in an OO language.
The language should provide a few simple tests, such as bit
comparison and pointer comparison, but it is the responsibility of
each class to provide a criterion for equality of its instances.

Peter
From: billb@nasty (Bill Burcham)
Subject: Re: GCC 2.3.2 implementation of signatures for C++
Organization: First National Bank Of Chicago, Chicago IL, USA
Date: Wed, 23 Dec 92 15:16:15 GMT

In article <1h8cg6INNccc@ector.cs.purdue.edu> gb@cs.purdue.edu (Gerald  
Baumgartner) writes:
> Just ready for Christmas, a beta test version of our implementation of
> signatures for C++ has been released and is available by anonymous FTP
(munch)
> What are Signatures anyway?
> ---------------------------
> 
> Roughly, signatures are type abstractions or interfaces of classes.
> They are related to ML's signatures, categories in Scratchpad II,
> definition modules in Modula-2, interface modules in Modula-3, and
> types in POOL-I.
(munch)

.. or protocols in Objective-C?  Is there any plan to add a distributed  
object capability using signatures?

--
+--------------------------------+----------------------------------+
|          Bill Burcham          | "Make no small plans; they have  |
| First National Bank of Chicago | no magic to stir men's souls"    |
|    billb@fnbc.com  (NeXTmail)  |      Daniel J. Burnham           |
+--------------------------------+----------------------------------+
From: bongalon@tcad05.intel.com (Ben Bongalon)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Date: 21 Dec 92 22:10:15 GMT
Reply-To: bongalon@tcad05.intel.com (Ben Bongalon)
Organization: Intel Corporation, Santa Clara, CA USA


In article <1992Dec17.221333.3023@midway.uchicago.edu>,
dave@alex.uchicago.edu (Dave Griffith) writes:
|> In article <BzF6uA.1u3@inews.Intel.COM> bongalon@tcad05.intel.com
(Ben Bongalon) writes:
|> >
|> [A whole lot of really quite good stuff.]
|> 
|> Seems to me like we've gone around enough to realize that we're all finally
|> talking about the same thing, just from different views.  Now that we've
|> got our respective terminologies agreeing, I feel like it's time for a 
|> blatant try at closing the discussion.
|> 
|> Values can be indirectly implemented as objects. The only benefit of this 
|> (and yes, it's a large one) is that languages do not require two separate 
|> semantic constructs for two somewhat related mental constructs.  The direct 
|> costs of this is that in current languages this implementation is not quite 
|> safe, and requires unenforced coding restrictions to ensure that
values really 
|> act as values.  This is a known bug source, and should be approached
as one.  
|> A possible indirect cost is that it places one further interpretation step
|> between a programmer's design and her implementation. As decreasing the 
|> design/implementation distance is one of object oriented programming main
|> strengths, this should be considered accordingly.  Given these costs and
|> benefits, I believe that a language could fruitfully be designed
which supports
|> values and objects as separate concepts.  The costs and benefits
probably don't
|> justify writing a new language to specifically test this hypothesis, and 
|> certainly don't justify increasing the complexity of already overly complex
|> languages (C++, Eiffel, and Ada in particular).  But if you just
happen to find
|> yourself designing a new language which uses some OO concepts and extends
|> them with other semantic modelling capabilities (relations, in my
case), then
|> it's probably worth trying them out.  If it pays off, it's part of the 
|> benefits of breaking new ground.  
|> 
|> The only thing I can find in the above which is even remotely objectionable
|> in the above is describing Eiffel as overly complex, a statement I'm
not even
|> slightly interested in debating.   Other than that, I think that we've said
|> all that needs to be said on the subject.
|> 
|> -- 
|> Dave Griffith, Information Resources, University of Chicago,
|> Department of Surgery                       dave@alex.bsd.uchicago.edu
|> Oh, by the way, I almost forgot.  Godot called.  He said he'd be late.

Amen  :-)

Ben Bongalon
Intel Corporation
From: phil@honda.epi (Phil Magrogan)
Newsgroups: comp.object
Subject: Re: OOA&D Methodologies
Date: 23 Dec 92 20:50:29 GMT
Reply-To: phil@honda.epi
Organization: General Electric

Another Tool you might want to look into is the OMT developed by GE's Research Center.  
You can contact the Advanced Concepts Center in Valley forge PA or give me a 
call and I can give you some names there.
Phil Magrogan
315.456.3096
From: steinman@hslrswi.hasler.ascom.ch (Jan Steinman - Bytesmiths, 3946)
Newsgroups: comp.object
Subject: Re: Equality
Date: 31 Dec 92 07:52:28 GMT
Reply-To: steinman@hslrswi.hasler.ascom.ch
Organization: Ascom Hasler AG

In article 2261@afs.com, greg@afs.com (Gregory H. Anderson) writes:
>In article <1992Dec22.152021.4209@kei.is.s.u-tokyo.ac.jp>  
>jeff@is.s.u-tokyo.ac.jp (Jeff McAffer) writes:
>
>> > May two objects of different classes be equal?
>> 
>> Yes
>
>Please explain how that could be.

Well, using a Smalltalk example: "1 = 1.0". "1" is a SmallInteger, and "1.0"
is a Float. If you simply think of "=" as just another message send to some
object, then it is up to the receiver of the message to determine if he/she/it
is equal to the message argument. OOP systems that do not allow this are not
polymorphic. (I don't want to start *that* discussion, but many people --
Smalltalkers, mostly -- view polymorphism as essential to object orientation,
while many others -- C++ers, mostly -- see polymorphism as unnecessary to OO.)

>Just because they happen to be exactly  
>the same size, and happen to involve exactly the same instance variables,  
>which happen to contain the same values, are two objects from different  
>classes equal?

Absolutely not, unless they have defined that function as their equality
message. About the only thing you can say for sure is that an object should
be equal to itself.

>In Objective-C, this would be prima facie impossible,  
>because the first instance variable is always 'isa', which points to the  
>class. If two objects were equal in the sense I just defined, they would  
>*have* to be members of the same class, or else their 'isa' pointer would  
>be different. Maybe I'm missing something?

What I think you're missing is that "hybrid" OO systems provide you with
built-in biases and notions about certain operations. Everyone with a C
background has a preconceived notion of equality. Once you view "equals"
as just another message, it becomes easier to imagine different uses for
it. To take your example, you may decide that two objects should be
considered "equal" if only a certain instance variable is equal, and that
instance variable may be a computed hash or checksum of all the other instance
valiables.

Another example might be that two objects are considered equal if a field
representing the primary key in a database is equal.

---
: : Jan Steinman, Bytesmiths			   steinman@hasler.ascom.ch : :
: : 2002 Parkside Court, West Linn, OR 97068-2767 USA	    +1 503 657 7703 : :
: : Beundenfeldstrasse 35, CH-3013, Bern, Switzerland	    +41 31 999 3946 : :
Newsgroups: comp.object