In article <firstname.lastname@example.org>,
Lennart Augustsson <email@example.com> wrote:
>firstname.lastname@example.org (Paul Wilson) writes:
>> Matthias Blume <email@example.com> wrote:
>> > - Things that _actually_ look the same in each and every
>> > respect_are_ the same.
>> No. This is bad philosopy. Things that are indistinguishable
>> given a certain subjective point of view may become distinguishable
>> when you learn more about them.
>Do you have a problem with reading? :-)
>Matthias Blume wrote "in each and every respect"; how can something
>look the same "in each and every respect" and then be "distinguishable
>when you learn more about them"? If objects can be distinguished when
>you learn more about them then they were not equal in each and every
"In each and every respect" must be understood in the context of the
information available. When we're programming, we are necessarily dealing
with abstractions and (often) approximations. The data type in the
programming language almost always doesn't include all the information
about the corresponding object in the real world. For instance, the IRS's
database doesn't have my fingerprints, DNA sequence, or complete quantum
state (the latter is probably the closest thing there is to "object
identity" for tangible objects in the real world -- object identity for
abstract concepts (e.g. numbers, imaginary objects, counterfactual
proposals) is still the subject of philosophical debate).
Someone else wrote that distinction after mutation is one way that objects
might "look different". The problem with including this as part of how an
object "looks" is that you may not want to modify an object just to find
out if it's the same as another object; it's like determining whether
someone is a witch by submerging them in water: if they're a witch they'll
survive (in which case you'll burn them), but if they're not they'll drown.
Functions that test for object identity equivalence answer the question
"would object A change if I modify object B?" without actually performing
the modification. In languages with mutation and multiple references to
objects, this is a useful question to ask.
BBN Corporation, Cambridge, MA
(BBN customers, call (800) 632-7638 option 1 for support)