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

"Jim Melton" <Jim.Melton_at_Technologist.com> wrote in message news:3BC3DF3A.275FD244_at_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.

Neither a reference nor a pointer is a logical construct in the manner you used the term. Both are physical constructs. A relation is the logical equivalent of a conceptual reference.

> > 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.

Both "reference" and "pointer" are physical constructs. A relation is the logical equivalent of a conceptual reference.

> It is the difference between a table and a view.

I agree. Both a table and a view are logical relations. Both a reference and a pointer are physical constructs. In terms of use, no important difference exists between a table and a view. In terms of use, no important difference exists between a reference and a pointer.

> Note that only
> you used the word "pointer" above.

A pointer by any other name...

> You are the only one who consistently
> equates reference with pointer.

I am not accountable for the inconsistency of others. Reference is a concept. The logical equivalent of that concept is relation. What you previously called a reference is a physical equivalent, which equates to a 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.

But they are exposed. As it says above, everything is a pointer.

> What
> the compiler does "under the covers" is irrelevant.

Smalltalk exposes pointers to users. All named variables are pointers and this is not kept under the covers.

> 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 Smalltalk, a variable name is translated to a memory address (or perhaps even a register) by the compiler. The memory address is certainly a pointer. The memory addressed by this pointer or perhaps even the register also contains a pointer to a memory address. You would say that Smalltalk 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 those semantic differences would be...?

> 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.

The combination of a relation name, column name and candidate key value is also a reference to a persistent object variable. The concept is old. The physical construct Adrian describes is old too: it's called a pointer.

> > 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.

What significant difference exists between a reference and a pointer?

The logical equivalent of the reference concept is a relation. Both what you call a reference and what you call a pointer are physical equivalents of the concept.

> > > 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.

Under the covers, I am told that Smalltalk often does away with unnecessary pointers during optimization. Both the Smalltalk FAQ and the official Smalltalk standard explicitly make all named variables implicit pointers.

> It has nothing to do with the logical concept.

I believe you are mixing models. What you call a reference is a physical equivalent to the reference concept. A pointer is also a physical equivalent to the reference concept and equates to what you call reference. The logical equivalent to the reference concept is a relation.

> > > > > - 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.

Why not? I live in both Canada and the USA. Do I change my identity when I cross the border? If the lifetime of the object entails multiple locations, your previous statement implies that identity should not change when the location changes. The spreadsheet is just another location.

> Otherwise, you
> would have two objects of equivalent state (at some snapshot in time).

Do you realise how fundamentally and how thoroughly you have just impeached OID or "reference"?

You are saying that OID provides an identity for variables and not for data. The variable in the database is different from the variable in the spreadsheet, and I would agree. However, both variables describe a single real-world entity with unique identity.

You are saying that OID does not provide any facility to identify the actual data or real world entity.

The value of a candidate key identifies both. When one combines it with a relation variable and the name of a column, it identifies an object variable in the database. A spreadsheet identifies its variables using a coordinate scheme. Even in the spreadsheet or on a fax, the candidate key value identifies the same entity in the real world.

The logical identity of relational databases remains constant independent of location, medium or application.

> > > 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.

Syntax is irrelevant.

> > > 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".

No, I did not. I asked how one preserves identity when one uses spreadsheets and faxes to communicate data about "objects".

> Identifying the "correct" variable in "the database" is always
problematic.

Not in a relational dbms. The user observes the values in the spreadsheet or on the fax and uses those values to identify variables within the database.

> > 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.

Bee or no bee, humans consume identity information.

[Quoted] > > > > > - 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.

If it is impossible, why did you state that they should give you an error when you try to access a deleted object through them? Or was that Adrian?

> 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.

I do. I would call proceeding as if everything were okay "not knowning" that it is dangling. I realise that C++ usually does proceed (at least for a while.)

> In a database, a ROWID is analogous to a pointer.

I agree.

> 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.

It depends on how the database defines ROWID. In SqlBase, a ROWID combines a pointer with a transaction sequence number or timestamp. However, I do not defend ROWID or any other pointer exposed in the logical model of a dbms.

> Adrian's described reference knows when the referent does not exist. I
don't
> know of any other construct that does the same thing.

See ROWID in the SqlBase product documentation.

[Quoted] > > > > 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"?

As variables in relation variables uniquely identified by a combination of relation variable name, candidate key value and column name. Or as values in relations uniquely identified by a combination of relation, candidate key value and column name.

> 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?

One must construct an application programming language object variable based on the observable properties of an object value from the database. To update the database, one must change the value or state of a database object variable based on the observable properties of an object value in the application.

How is encapsulation violated?

> > > 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).

If that is the case, you misinterpreted my statement that relations expose objects directly and did not answer my question as you claimed. I never said that relations expose the internal implementations of object values or variables.

Relations, themselves, are explicitly not encapsulated. They exist to directly expose their constituent object values or variables. The domains or object classes that define the types of those object values and variables are encapsulated. Received on Sun Oct 14 2001 - 03:44:13 CEST