NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/object/4531

Internet Message Format | 1992-12-15 | 6.2 KB

Path: sparky!uunet!olivea!spool.mu.edu!uwm.edu!linac!uchinews!alex!dave
From: [e-mail] (Dave Griffith)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Message-ID: <[e-mail]>
Date: 15 Dec 92 01:44:20 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (News System)
Organization: University of Chicago
Lines: 106

In article <[e-mail]> [e-mail] writes:
>Jan Steinman (the roving poster) writes:
>
>{ bunch of good stuff deleted }
>
> ! >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.
>
>Can you give an example of a real world value which is concretely
>definable and describable in the real world but not in a computer as
>an object (or anything)?
>

Arrrghh!!   The question is not "can be modelled", the question is
"is this form of modelling directly supported (and enforced) by the language".
If this distinction isn't useful, there's no reason to have object oriented
languages at all.  After all, all of the standard object oriented programming
language concepts can be modelled in C using records, pointers, and
function pointers.  The reason for direct language support for object
orientation is not that it adds any functionality.  The reason is that it
brings the level of programming closer to the level of human cognition.
Of course objects can model values.  So can a Turing machine.  The question
is whether it would be valuable to provide direct linguistic support for the
concept value.

A more extreme example, and one that I'm working on in my language, is
inter-object relationships.  There is no _direct_ way in current object-oriented
languages to say "object A stands in relation B to object C".  There are
any number of _indirect_ ways of saying this.  A may be an instance variable
of C, C may be an instance variable of A, the pair (A, C) may be in some
dictionary B, etc. ad infinitum.  Things get even more complex if relations of
arity other than two are allowed, if relations may be many-to-many, if
constraints on relations hold.  All of these may be modelled by current
languages, but none has direct support for the concept "relation".  As such,
programmers spend time reducing relations to concepts that are modelled
directly by the language.  In addition to being time consuming, this process
of reducing relations is a beautiful place for bugs to manifest.  Whether
relations and values can be added to the object oriented paradigm without
excessive cost is as of yet unknown (I've still got some fairly hairy
efficiency problems to work out in my compiler.)

> ! 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.
>
>It seems to me that people are confusing implementation with
>behaviour.  What we are suffering from here is insufficient
>specification.  People are all up in arms because they can't create
>another False.  The problem is that they know there is a False!  A
>properly specified system would simply spec Boolean and leave the rest
>to the implementor.  Ditto for SmallInts.
>
>You just know too much is all.  Hardware, software, OS, VM, mutable,
>immutable?  Who knows?  If you care, you are doing something wrong!
>It's not really your fault either.  The system forces you to know so
>much because there is no decent spec.  Sit back sometime and take a
>good hard look at how much implementation knowledge you are using in
>your systems.  I think you will be surprised.  You can barely help it.
>The methods and vars are just there, tempting you.
>
>As for the difference (if any) between values and objects: value =
>some 'thing' that does not change.  Right?
>

Actually, immutability is only a small part of being a value.  The important
part is lack of identity.  All '3's are the same, regardless of their history.
On the other hand, standard objects are only equal if they are identical.
Immutability is necessary for values, but not sufficient.

>Does that mean that the actual bits don't change?  So it is bit
>identity that matters?  If so, your true and mine are different! (we
>have different bits) This is appealing to existentialists for sure but
>would make coding a nightmare.  Who's is right?  Can we decide?  Does
>it matter?  Anyway, what is the "value" of true that pre-existed and
>is being 'modelled' as an object/value in the computer?

Whether the actual bits are changable is rather beside to point.  The idea
is that a values essential nature cannot change, whatever that means.  This
is usually easiest if the bits are unchanging, but that is not necessary.

>
>If the bits can change and move, then I don't see the diff between
>"value" and "object that does not change".  In short, why can't a
>value be an object?  What does explicitly knowing/using the fact that
>something does not change help us?

It _does_ allow a lot of optimization.  There are occasions where copy
semantics are cheaper than reference semantics.  But at a higher level, it
seems to be necessary to allow safe programming.  We need to know that noone
can subclass our Integer class so as to allow the old Fortranism of changing
3 to 5.


--
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       [e-mail]
Oh, by the way, I almost forgot.  Godot called.  He said he'd be late.