Re: The Fact of relational algebra (was Re: Clean Object Class Design -- What is it?)

From: Jim Melton <Jim.Melton_at_Technologist.com>
Date: Wed, 10 Oct 2001 05:40:16 GMT
Message-ID: <3BC3DF3A.275FD244@Technologist.com>

Bob Badour wrote:

> "Jim Melton" <Jim.Melton_at_Technologist.com> wrote in message
> news:3BB800E6.E6F67388_at_Technologist.com...
> >
> > Bob Badour wrote:
> >
> > > "Adrian Veith" <adrian_at_veith-system.de> wrote in message
> > > news:9nl4hf$ndq$1_at_wrath.news.nacamar.de...
> > > > I have never talked about pointers. I talked about a reference.
> > >
> > > A reference is a pointer.
> >
> > > > I do mind. I do not attempt to redefine programming language terms
> > > > when posting to programming groups, and I ask that you not attempt to
> > > > redefine database management terms when posting to database management
> > > > groups.
> >
> > Hmmm. Looks like a redefinition to me. A reference is a reference. It is
> not a
> > pointer. It has more in common with an automatically created unique ID used
> as
> > a primary key than with a pointer.

>
> From the standard vocabulary for programming languages:

Irrelevant. For one who is keen on physical independence, you refuse to grant the difference between logical and physical when it comes to object references. When you say that a reference (logical construct) is a pointer (physical construct) you are redefining terms.

> From the Java Language Environment:

>


>     All references to allocated storage, which in practice means all

> references to an object, are through symbolic "handles".

>     The Java technology memory manager keeps track of references to objects.

>     When an object has no more references, the object is a candidate for

> garbage collection.

>

> As you can see above, in Java, a reference is a pointer to a pointer.
> Additional levels of indirection do not change the pointer nature.

But they do. It is the difference between logical construct and a physical implementation. It is the difference between a table and a view. Note that only you used the word "pointer" above. You are the only one who consistently equates reference with pointer.

> From David Smith's Smalltalk FAQ at
> http://www.dnsmith.com/SmallFAQ/PDFfiles/LanguageQuestions.pdf:

>

> 4.40 . What do Smalltalk variables hold?

>

> It is sometimes said that Smalltalk has solved the 'pointer problem' since
> Smalltalk
> appears to not have any pointers at all. Smalltalk has solved the 'pointer
> problem',
> but it did it by making everything a pointer rather than eliminating them.
> Since
> everything is a pointer (and there are no pointer manipulation operations),
> Smalltalk
> does not have the exposures of, say, C or C++ to pointer abuse.

Again, you miss the point. Since they are not exposed, they do not exist. What the compiler does "under the covers" is irrelevant. In FORTRAN, a variable name is translated to a memory address (or perhaps even a register) by the compiler. The memory address is certainly a pointer, but you wouldn't say that FORTRAN uses pointers.

> In C++, of course, the only differences between references and pointers are
> syntactic.

Posh. There are semantic differences between pointers and references in C++.

And Macintosh Pascal uses a "handle" to reference relocatable memory. Yes, all modern programming languages have a notion of a pointer (including pointers to pointers).

But Adrian was not describing a programming language pointer. He was describing a reference to a persistent object (which is not intrinsic to *any* programming language. So it is a new concept.

> How, exactly, have I redefined reference or pointer? Your description seems
> more of a redefinition than mine.

You have consistently redefined reference AS pointer. Reference is NOT a pointer.

> > Since your premise is false, the rest of your argument is moot.

>

> So you claim, but can you really support the assertion? The Smalltalk FAQ is
> at least honest about references.

The Smalltalk FAQ provides some "under the covers" insight into the implementation of the language. It has nothing to do with the logical concept.

> > > > - it *must* never change throughout the lifetime of an object.
> > >
> > > How does it achieve this when I embed the object in my Excel spreadsheet,

>


> > > print out the spreadsheet and fax it to someone else?

> >
> > You cannot embed the object in your spreadsheet. OO 101: Objects have
> identity.

>

> In which case, it should maintain identity when I embed it in my
> spreadsheet. I don't see the connection between your two statements. You
> aren't suggesting, by any chance, that OID or references determine storage
> location, are you?

Nope. I'm just saying that EITHER the object "lives" in your database OR it "lives" in your spreadsheet. It cannot "live" in both places. Otherwise, you would have two objects of equivalent state (at some snapshot in time).

> > You may copy values to your spreadsheet, you may include the reference to
> the
> > object in your spreadsheet (if it supports that)
>
> Wait a second! I thought users never use OID.

I didn't specify a syntax.

> > so it can dynamically update
> > the spreadsheet as the object state changes, but if the object is *in* the
> > spreadsheet, then it is *not in* the DB.

>

> It does look like your references determine location. It should not matter
> where the "object" is. If it has intrinsic identity, that identity should
> follow it wherever it goes. (I quoted "object" because you do not specify
> what you mean by object: variable, value, type etc. I assume you mean
> variable because variables have identity.)

No, the "object" (yes, variable is a suitable interpretation) has location. The reference merely "refers" to the object. Conceptually, it is possible to "move" objects around, but as above if it moves from one location it is no longer there (duh).

> > Your printout does not *contain* any objects, merely statically captured
> state
> > rendered in a printed form. The fax is a copy of that. These notions have
> > nothing to do with database management and are red herrings.

>

> It has everything to do with database management. When the other person
> picks up the fax, how does the person use the information on the fax to
> identify the correct variable in the database for manipulation?

Do you stretch out before making these leaps? You asked where an object "lived". In no case does an object "live" in a faxed copy of a printout of a spreadsheet.

Identifying the "correct" variable in "the database" is always problematic. If the object "lives" in the spreadsheet, then the user identifies the variable by opening the spreadsheet and "navigating" to the appropriate cell (identified by a "reference" such as C35).

> What happened to identity? Or did we print out the OID for human consumption?
> In
> your world of OID based identity, do humans no longer communicate directly?
> Can you believe that people accuse ME of platonic idealism???

No, but you've sure got a bee in your bonnet about OIDs and human consumption.

> > If the object referred to by your spreadsheet is subsequently deleted from
> the
> > database, the spreadsheet is no longer valid. Excel already has notions of
> > broken links (ever seen a #REF in a cell?).
>
> If the spreadsheet is statically captured state, why should it break?

I can't keep up with you. Who ever said the spreadsheet was static? The PRINTOUT is static. I assumed that the spreadsheet was dynamically displaying the dynamic state of the database object (assuming the object "lives" in the database and not in the spreadsheet).

> > > > - it should give you an error if try to access an object, that has been

>


> > > > deleted.

> > >
> > > As would any dangling pointer, which is just one reason why pointers
> prove
> > > so inflexible and ineffective.
> >
> > No, pointers don't know they are dangling which why they are so inflexible
> and
> > ineffective.

>

> They do (or should) as soon as you attempt to dereference them. Of course,
> some implementations of references (pointers) are more robust than others.

In garbage collected languages (Smalltalk, Java), it is impossible to have a dangling pointer. In other languages (C++) dereferencing a dangling pointer usually results in a core dump or worse. I don't call that the pointer "knowing" that it is dangling.

In a database, a ROWID is analogous to a pointer. It doesn't necessarily dangle, as another row could be put in the same physical location as the deleted row, but a reference through the "dangling" pointer would be incorrect. Adrian's described reference knows when the referent does not exist. I don't know of any other construct that does the same thing.

> > > How exactly does this new reference type differ from the relational
> method
> > > of simply exposing the object directly?
> >
> > Exposing the object directly violates encapsulation. It exposes
> implementation
> > details that are properly abstracted behind the object interface.

>

> Pointers, I mean references, do not expose objects directly?!? Something
> must expose objects directly in order for users to interact with them.
> Navigational systems expose them through pointers (references if you
> prefer), and relational systems expose them through relations. Please note
> that the exposed objects do not expose their internals, which means that
> they remain encapsulated in either system.

How does a relational database "expose objects directly"?

Much as you might wish otherwise, the current state of the art is that not all things can be accomplished via set operations internal to the RDBMS. For those cases, database values (since there is typically NOT a tight language binding to allow direct access to variables -- except in object databases) must be "exposed" to a programming language. How is the encapsulation of the object maintained then?

> > I don't expect you to agree with me or to see the subtlety of the
> difference,
> > but it is the answer to your question.

>

> I see the difference; I am not sure if you do. You assume that relations
> equate to object classes, and I assume they do not. Relations are
> unencapsulated sets while object classes are encapsulated data types. Object
> classes equate to relational domains. I don't think the difference is
> particularly subtle, though; I find it rather stark.

I don't assume any such thing. At no time (until now) were we discussing the difference between relations and domains. We were discussing exposing and encapsulation (which are opposites).

As to the rest of your post, I'd forgotten what a waste of time it is to try to carry on a conversation with you.

--
Jim Melton, novice guru             | So far as we know, our
e-mail: Jim.Melton_at_Technologist.com | computer has never had
v-mail: (303) 971-3846              | an undetected error.







text/x-vcard attachment: Card for Jim Melton

Received on Wed Oct 10 2001 - 00:40:16 CDT