HDTenEightyP/NetNews huggingface dataset:
From: steinman@hslrswi.hasler.ascom.ch (Jan Steinman - Bytesmiths, 3946)
Subject: Re: Object hidden state and side effects
Reply-To: steinman@hslrswi.hasler.ascom.ch
Organization: Ascom Hasler AG
Date: Sun, 13 Dec 1992 15:21:36 GMT

In article 18439@crd.ge.com, eaker@ukulele.crd.ge.com (Chuck Eaker) writes:
>In article <knight.724021213@cunews>, knight@mrco.carleton.ca (Alan Knight) writes:
>
>|> In Smalltalk one cannot delete an object of any kind. One can,
>|> however, create numbers perfectly well. 
>|>   Fraction numerator: 3 denominator: 4 
>|> 
>|> is perfectly valid Smalltalk code which creates a new fraction with
>|> value 3/4. Why is that crazy?
>
>It's crazy because it is not an example of creating a value. The
>value 3/4 has been around a long time. What this example creates
>is yet another digital representation of that value.

Oh, sorry for the misunderstanding. Will all C++ compilers that store the
value "3/4" in binary form *please* refrain from doing so? Instead, they
are to immediately begin using the *real* "3/4" that has been around a long
time.

I don't see the difference between calling "3/4" an object or something else.
But let's make it more interesting; let's make it "2/3". In order to properly
and accurately represent that in C++, one will have to (oh no!) create an
object, since "2/3" has obviously not been around long enough for computer
makers to wire it into their architecture!

Chuck has simply mistaken one reality (the abstract notion of immutable value)
for another (what portion of immutable values computer manufacturers have
chosen to model in hardware).

>In short, software must use objects to represent values.

So far, so good, but...

>This is
>why the distinction between values and objects is of enormous
>importance. Software objects are used to model real world objects
>as well as real world values. Modeling objects with other objects
>is far more straight-forward than modeling values with objects.
>The field of numerical analysis is all about the difficulties
>which arise when one is forced to use objects to represent values.

Huh? Let's replace "object" (a loaded term in this context) with "thing". Let's
further agree that a fraction, or an integer, or the set of values "1", "2",
and "3", or for that matter, the set of values endorsed by the Republican
National Convention, are all "things". None of them *are* the set of binary
patterns that represent them in a computer's memory, but must be represented or
modelled since they are abstract. Some of them are modelled in hordware, some
must be modeled in software.

If you accept this premise, do you still insist that it is fundamentally
necessary to represent "family values" in a different manner than the values
"1 2 3"?

---
: : 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 42 47 11 : :

Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Implementation of multiple inheritance?
Keywords: multiple inheritance
Organization: Object Systems
Date: Fri, 18 Dec 1992 02:16:20 GMT

In article <BzDnvq.H86@inews.Intel.COM> dmarer@td2cad.intel.com (Dennis Marer) writes:
>Howdy,
>
>	I've been working with OOP for a while, and only recently thought
>about needs for multiple inheritance (from a discussion in this newsgroup,
>I think), and I was wondering how something like that would be implemented
>in an efficient manner.
>
>	I'm most familiar with C++, so I'll use that for examples...say my
>C++ compiler sees the following code:

Try the ARM by Ellis and Stroustrup.  There's lots of ways to do MI, 
both for implementation and method, but they give the suggested approach
for C++ (which is quite efficient for C++'s static typing).

bob
objsys@netcom.com
From: jb7m+@andrew.cmu.edu (Jon C. R. Bennett)
Newsgroups: comp.object
Subject: Re: Is Borland the leader in technology?
Date: 14 Dec 92 10:00:53 GMT
Article-I.D.: andrew.wf=CTpm00WD5Ni0uYz
	<henley.921211093204@wilbur.eng.auburn.edu>
Organization: Robotics Institute, Carnegie Mellon, Pittsburgh, PA


henley@eng.auburn.edu (James Paul Henley) writes:
>In article <Yf9te3C00WBEMfeqUe@andrew.cmu.edu> "Jon C. R. Bennett" <jb7m+@andr
> ew.cmu.edu> writes:
> >
> >because these days you need a computer to do chemical engineering, you
> >dont need chemicals to do computer science (unless you count caffine), but
> >in two courses the most that you can do is teach someone to be dangerous,
> >you cant teach them computer science. Look at it this way, if I took 2
> >chemical engineering courses, would you think I could do chemical
> >engineering? no, so why do you think 2 CS courses means that a Chemical
> >Engineer can do Computer Science?
> 
> Jon, the hard facts are this:  Chemical Engineers write Chemical Engineering
> Software.  That is a fact.  The problem is that they don't do it well, and
> they do it with outdated methods and inadequate tools.

corect me if im wrong, but did i not say just that?

> See my other post on this subject for a more detailed explanation of the 
> problem.

in your other post you give an example of the Tennesse Eastman plant where
you say that the only programmers that are not Chem E's are systems
analysts, must systems analysts that ive met would be proud to tell you
that they dont write code, please dont degrade programmers by saying that
systems analysts are programmers...... the problem with the plant in
question and with the process that you describe is that it starts with

>    Chemical Engineer writes some FORTRAN
>    Chemical Engineer give FORTRAN to programmer

when it should start with 

Chemical Engineer gives brief problem statment to the programer, and they
trade it back and forth until it is detailed enough for the programmer to
code from, that your process has this loop

>   REPEAT
>      Programmer writes some C and links with Chemical Engineer's FORTRAN
>      Programmer takes finished program to Chemical Engineer, and says:
>       "Is this what you had in mind?"
>      Chemical Engineer says:
>       "No, that is not at all what I wanted."
>   UNTIL time runs out, at which point Chemical Engineer lives with what
>      he has at that point 

tells me that you dont have a programing problem, you have a
communications problem, and until you address the communications problem,
you will continue to get poorly done programs as output.

jon
Newsgroups: comp.object
From: dave@alex.uchicago.edu (Dave Griffith)
Subject: Re: Object hidden state and side effects
Organization: University of Chicago
Date: Thu, 17 Dec 1992 22:13:33 GMT

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.
Newsgroups: comp.object
From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: Object hidden state and side effects
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
Date: Sat, 19 Dec 1992 21:46:06 GMT

In <1992Dec18.152823.888@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) 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.  

Control structures in Smalltalk aren't objects, they're methods. (at
least the obvious ones like ifTrue:, whileTrue:, do:). The advantage
of this is that it gives one a unified form for them and reduces the
complexity of the basic language. It's the same idea as functional
language that implement control structures using first-class
functions, or Prolog implement it's version of control structures
using logic clauses. It makes the language more extensible, since I
can add new control structures (e.g. a case statement) that are not in
any way different from the built-in ones.


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

Newsgroups: comp.object
From: rkod5@fel.tno.nl (R. Koolma)
Subject: Object Oriented Design <-> other design methods
Organization: TNO Physics and Electronics Laboratory
Date: Mon, 14 Dec 92 14:21:32 GMT
Keywords: OOD, OOP

We in our group are looking at OOD and OOP to investigate the advantages and disadvantages of OOD. For this we would like to here about as much cases as possible where OOD was used. We would like to know if things went faster and/or easier than with other methods. We would also like to know if the
resulting software is easy to extend and modifiable.

Please send by E_Mail.

Thanks in advance ......

Rolf Koolma
Fel-TNO, The Hague, Holland
e-mail : rolf.koolma@fel.tno.nl
From: jc@ri.cadre.com (Joe Cascio)
Newsgroups: comp.object
Subject: Re: Object Relations - was: Re: Object hidden s
Date: 17 Dec 92 14:37:42 GMT
Article-I.D.: fripp.1992Dec17.143742.16507
Reply-To: jc@ri.cadre.com
Organization: Cadre Technologies Inc., Providence, RI


>both of which can be implemented reasonably easily.  BUT all the
>other relationships are nightmares when it comes to
>implementation.  Especially secondary relationships like the
>relationship between the Road and the 4 wheels (which are part of
>the car.).  Can anyone give me pointers on some standard way of
>dealing with this?
>

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

I've encountered this problem, too.  It comes home to roost for me
as life-time control.  Who "owns" or implements those secondary
relationships?  In really nitty-gritty terms, where (in what scope)
do you put the collections (sets. lists, whatever) that implement
the relationship?

An approach that seems to have some promise starts with structuring
the design/implementation around the aggregation hierarchy of the
problem.  The aggregation instances (e.g., "car" in your post), own
(control the lifetimes) of the constituent instances.

Next, the secondary relationships can be implemented in (placed in
the scope of) the lowest common aggregator in the aggregation
hierarchy that controls the lifetimes of the objects that the
secondary relationship relates.

This may require that a top-level or "super-aggregator" class be
introduced to provide a global scope to implement relationships
like "rubber-meets-road" in your example.  You might have to have a
Transportation-system class which is at a sufficiently high
abstraction to "contain" the relationship.

As an example, we might have an aggregation hierarchy in which a
TransportationSystem has terminals, and trucks.  Terminals have
employees, routes, and customers.  "Have", in this context, denotes
aggregation.  So, for instance, the "terminal has routes"
relationship would be implemented in the Terminal objects.  A
secondary relationship like "truck is used by employee on route"
has as its objects, route and employee, both owned by Terminal, and
truck, owned by TransportationSystem.  So, the lowest common
aggregator is TransportationSystem.

It may not be perfect, but it does give you a first-cut design.

Note that in all of this, inheritance is not a concern.  In fact,
worrying about inheritance at an early stage of design can cause a
lot of problems.

---
* 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: haim@dancer.cc.bellcore.com (kilov,haim)
Subject: Re: Object Relations - was: Re: Object hidden state and side effects
Organization: Bellcore, Livingston, NJ
Date: Thu, 17 Dec 92 01:03:03 GMT

Yes, there is a way to specify associations (relations) between objects and
even to create a reusable generic library of primitive associations (like
dependency, composition, etc.). This is done at the information modeling
level and described in some of our publications (both Bellcore and some
conference proceedings). However, these primitive associations are not
isolated either. And, of course, it seems that implementing this in an
existing programming language is not straightforward, although - at the
very least - you have a precise specification obtained as a result of
information modeling. The elements of this primitive association library
are reused in all actual models (and we even managed to specify some of them 
in Object Z).

We deal here with operations jointly owned by several objects rather than
owned by only one of them. In other words, a message does not have a
distinguished recipient. This approach is stressed, e.g., in the Object
Data Management reference Model published by ANSI Object-oriented Database
Task Group in 1991.

Hope this helps.

-Haim Kilov
haim@bcr.cc.bellcore.com
Newsgroups: comp.object
From: mat@mole-end.matawan.nj.us
Subject: Re: Is Borland the leader in technology?
Summary: But is that what's happening?
Organization: :
Date: Wed, 16 Dec 1992 14:42:44 GMT

In article <henley.921215143128@wilbur.eng.auburn.edu>, henley@eng.auburn.edu (James Paul Henley) writes:
> In article <wf=CTpm00WD5Ni0uYz@andrew.cmu.edu> jb7m+@andrew.cmu.edu (Jon C. R. Bennett) writes:

> >>    Chemical Engineer writes some FORTRAN
> >>    Chemical Engineer give FORTRAN to programmer

> >when it should start with 

> >Chemical Engineer gives brief problem statment to the programer, and they
> >trade it back and forth until it is detailed enough for the programmer to
 
> And do in a month what could be done in a few minutes?  NO THANKS!

The first part of this story, as I read it, indicated that CODE went back
and forth for a few months, with all the labor that went into it, as the
design was worked out in code already executing.  The proposal, as I read
it, was that a problem description should get traded back and forth for
a day or two, and the code written once.

I don't think that would be much loss in productivity ...
-- 
 (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
Subject: Re: Is Borland the leader in technology?
From: philbo@arasta.uucp (Phillip Lindsay)
Date: Mon, 14 Dec 92 21:47:56 PST
Distribution: world
Organization: Phillip Lindsay, Tustin CA
Keywords: engineering

henley@eng.auburn.edu (James Paul Henley) writes:
> In article <H5NPVB1w164w@arasta.uucp> philbo@arasta.uucp (Phillip Lindsay) wr
>
> Agreed, the Software Engineer has an important role to play, but it is not
> being played in many cases.
>
> >domain?  A Chemical Engineer should be in a role where they best express the
> >needs. We need to be in role that best addresses their needs.  High level
> >tools alone is not the answer.
> >.....................comments deleted
>
> So, we don't need high level tools?  Or you don't want to develop high level
I did not imply this?

> tools?  What *is* the answer?  All I want to do is make life easier for both
> of us.  I want you to do what you do best, and let me do what I do best.  I
> realize that involves more that just developing the tools, but without them
> things are going to stay in the current rut.
>
I don't think my sentence implied that "we didn't need high level tools?"  I
was merely expressing the point that high level tools don't address all
issues.  For instance, a friend of mine (with a Computer Science background)
was working with several PHDs on an SDI project.  The scientist's speciality
was material science. They used "high level tools" on Sun Workstations
to design silicon and needed my friend's help to build tools which
understood the silicon and could test it with several tools and models in
a reasonable time frame (with the help of a Sun hosted number cruncher).
The project could not have been completed without his expertise.  The funny
thing is that he ended up designing silicon and becoming a department expert
before budget cuts chopped the department.
> James P. Henley Jr.
> Visiting Assistant Professor
> Department of Chemical Engineering
> Auburn University
>


--
Phillip Lindsay "Government for the Politicians for Japan."
INTERNET: 75230.300@compuserve.com ** UUCP: uunet!zardox!dhw68k!arasta!philbo
Phone: 714-385-2311 ** USMAIL: 2955 Champion Way, #175, Tustin, Ca. 92680
Newsgroups: comp.object
From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: Object hidden state and side effects
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
Date: Thu, 17 Dec 1992 01:53:31 GMT

In <1992Dec16.175126.14968@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:

>In article <1992Dec16.65250.10645@kei.is.s.u-tokyo.ac.jp> jeff@is.s.u-tokyo.ac.jp writes:
>>In article <1992Dec15.014420.6604@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:

> ... "Objects" as I have
>been using the term use reference semantics.  Two objects are only equal if
>they are identical.  "Values" use copy semantics for assignment. (What they
>use for equality semantics is a deeper and IMHO more interesting question, but 
>I digress.)  How these semantics are actually implemented is a implementation
>decision and should not be considered here.  

This definitely seems to be the root of the confusion. You mean
something different by "object" than I do, and I expect than Jeff
McAffer or Jan Steinman do.  If you call something an object only if
equality and identity are the same operation, then most OO langauges
already support the distinction being called for, since the equality
operation can be defined to be anything you like. This is certainly
the case for "value objects" in Smalltalk, such as Booleans, Numbers,
Symbols, etc. Somebody just posted that the same thing is true in
Eiffel. Maybe you can't do it in C++, but that's a whole other debate.

>>about it.  They are just objects to which I can send messages, pass as
>>parameters...  They have a protocol... and allow only those operations
>>that are in line with their "essential sameness"

>But most languages have no way to _enforce_ the requirement that they "only
>allow operations that are in line with their essential sameness".  They
>treat their builtin classes as "special", and don't allow programmer defined
>classes to be defined as special in the same way.  It would be useful in C++
>for instance to define a Bignum class which didn't allow the programmer
>to set 3 equal to 5, even if that Bignum class is eventually subclassed.  
>Subclassing can blow away the original programmers intent of immutability, 
>with possibly disastrous effects on program correctness.

The only "special" distinction in Smalltalk is between SmallIntegers
and everything else.  The distinction is effectively invisible in
normal use.  Also, what you are asking for is possible in C++ (but not
in Smalltalk). In C++, private class members are not visible to
subclasses. If you don't provide any destructive functions then they
cannot be added when you subclass. I think you can circumvent this by
writing "friend" functions, but that's an explicit mechanism provided
to circumvent the language restrictions in the name of performance.

-- 
 Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x1027 
 Dept. of Mechanical and Aerospace Engineering              
 Carleton University, Ottawa, Ontario, Canada, K1S 5B6
From: js@montaigne.lif.icnet.uk (Jack Shirazi <js@biu.icnet.uk>)
Newsgroups: comp.object
Subject: Visual programming
Date: 17 Dec 1992 10:38:58 -0000
Organization: Imperial Cancer Research Fund
Distribution: world
NNTP-Posting-Host: montaigne.lif.icnet.uk

I've seen a couple of visual programming environments, and used one
that was implemented using Smalltalk, and I notice that they are
really dataflow programs. Does anyone have any ideas about a way of
visual programming which allows you to create and use objects
interacting with each other.  I realize that the Smalltalk
implementation has interacting objects uderlying it, but at the visual
level you have data comming in, processed through some functions and
output.  I know the question here is unclear, but I'm having trouble
thinking up a visual program which is not a dataflow diagram.
-- 
       Jack               js@bison.lif.icnet.uk
                         
If you only have a hammer, you tend to see every problem as a nail.
                -- Maslow
Newsgroups: comp.object