Re: Objects and Relations

From: David BL <>
Date: 8 Feb 2007 00:01:26 -0800
Message-ID: <>

On Feb 8, 12:09 pm, "Marshall" <> wrote:
> On Feb 7, 6:12 pm, "David BL" <> wrote:
> > On Feb 8, 6:26 am, Bob Badour <> wrote:
> > > >>Consider the following
> > > >>void foo(Employee* p1, Employee* p2)
> > > >>{
> > > >> // Q1. What does this mean?
> > > >> if (p1 == p2) ...
> > > Conditional test whether p1 and p2 point to the same variable.
> > Bob is confused about the difference between 'variable' and 'object'.
> Objects are a specific kind of first-class variable. The term is not
> popular in the OO world but it is nonetheless accurate.

I would be interested to know where it is defined like that in the literature.

The term 'variable' is very popular in the OO world, and I've never heard of it being used like that.

> > Since the object type is (incorrectly) named
> > "Employee" on casual reading it may appear to be true if and only if
> > p1 and p2 designate the same Employee.
> Just repeating the same claim over and over doesn't really advance
> the coversation.

You claimed confusion doesn't exist because no one will confuse an employee object with an employee human. I agree of course that exactly that confusion won't happen in practice. I have pointed out that the actual confusion that may occur is more subtle as shown by the above examples. I am not merely repeating myself. Your simple counterargument to the confusion doesn't hold here. Someone can well understand the difference between object and external entity yet make mistakes about how to interpret the code, because the incorrect interpretations read well and appear to make sense. I note as well that many naive OO programmers believe there is something evil about two employee objects that represent the same human employee, as a direct result of their improper understanding of the semantics of object identity (and their improper naming convention helps them to "deduce" that fallacy). If you like, have a read of the thread called "Object Identity" that I started about 6 months ago on comp.object to see this confusion. I believe it is widespread.

In fact the nature of object identity has historically been a repeated source of confusion and difference of opinion on comp.object.

> > In my designs I aim for correctness and brevity. Correctness is not
> > negotiable. An incorrectly named class is not an option.
> Of all the areas to worry about correctness, you're focusing on
> naming? Naming is important, but I've never heard it elevated
> to a correctness issue before. Do you imagine being able
> to write some kind of theorem prover that will tell you
> if a name is good or not?

My original intent was not to have a discussion about good ways of naming things. Instead it is all about drawing attention to a semantic lie (no matter how technical). I don't really care how you name things in your code. You can use randomly generated identifiers for all I care! I'm talking about theoretical matters and you are talking about more practical ones. I have a kind of mind game experiment where I picture OO source code where everything has been named correctly. Ugly names may reveal bad approaches.

I'm not particularly interested in knowing how often confusion over object identity causes real errors in code. Rather, what interests me is how the semantic appears to have repercussions about the best way to write programs, and whether there are some simple criteria that helps to choose the right approach at the right time (as we decompose problems).

If you think OO is about modeling external entities (as distinct from systems programming, simulation, game development etc) then you have a radically different opinion of what OO is all about. Perhaps this is the real question that needs to be discussed.

> And how can you be claiming
> brevity when you want to put a "-model" suffix on the name
> of every class in the application domain?

As I said before, it's a non-problem because you should be using RM to postulate facts about entities external to the abstract machine.

> You still haven't provided any evidence that actual programmers
> actually get confused about something that they wouldn't
> get confused about if they just used a suffix on the name.

Here is one: I have heard it argued that classes should not have a Clone() method because it doesn't make sense, and the real reason is that they didn't remember/realise that it is actually only a model being cloned.

Confusion like that affects the high level design. Received on Thu Feb 08 2007 - 09:01:26 CET

Original text of this message