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:3BB800E6.E6F67388_at_Technologist.com...
>
> Bob Badour wrote:
>
> > "Adrian Veith" <adrian_at_veith-system.de> wrote in message [Quoted]
> > 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:

15.06.08
call by reference
call by address
call by location

    A call in which the calling * module provides to the called     module the addresses of the parameters to be passed.

NOTE - In a call by reference, the called module has the ability to change the values of the parameters stored by the calling module.

15.10.02
indirect referencing

    Referencing via a data object that points to a referenced     language construct.

NOTE - The referencing may be done along a chain of data objects, in which case each data object, except the last, points to the next, the last data object pointing to the referenced language construct.

15.03.20
pointer (in programming languages)

    A data object whose data value is the address of another     data object.

15.03.21
null pointer

    A pointer that explicitly does not point to any data object.

NOTE - Depending on the programming language, the null pointer has a representation called "nil", "null", etc.

From the standard vocabulary for organization of data:

04.09.04
pointer (in organization of data)

    A data element that indicates the location of another data     element.

NOTE - Differs from the entry 15.03.20 in ISO/IEC 2382-15.

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.

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.

Every value in every variable in Smalltalk is a pointer to the value it represents?.
However, rarely does this fact become visible in programs. Since all variables always
hold pointers to objects, it is common to speak as if variables held the objects
themselves. Rather than saying the string referenced by name it is common to say the
string in name.

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

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

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

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

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

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

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

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

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

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

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

> > > The construct of the "reference" brings the task of key-generation to
the
> > > DBMS.
> >
> > Unfortunately, it hides the identity of data from the user at the same
time.
> > A DBMS can generate unique key values without resorting to pointers.
>
> DBMS-generated unique key values provide no data identity values to the
user
> either.

What do you think the key value is?

> > > You can look at a reference and it tells you: who or what it is and
> > > when it is.
> >
> > I sincerely doubt that many human users can tell anything by observing a
> > reference.
>
> I sincerely doubt that many human users can tell anything by observing a
> DBMS-generated unique key either.

Users do not observe key values in isolation; users observe relations. The relation and the column name determine a declared type, which the user can easily observe. Combine those with the key value, and the user can observe the most specific type as well.

> > > Since my design skills are week ( and I am not an advocat for RDBMS
like
> > > they exist now), please show us your simple approach in SQL.
> >
> > Since I am not an advocate of SQL, why should I? If you want to
criticize
> > SQL databases for lack of domain support, be my guest. I would encourage
> > you.
>
> And if you cannot offer any viable alternative, why are you wasting
everyone's
> time?

If you think my message is a waste of time, don't read it. Nobody forces you. Since I have already pointed out that relational domains are abstract data types, the relational approach should be obvious to anyone willing to think about it.

> The request for SQL was because that is the lingua franca of RDBMS.

I disagree. Predicate calculus is the lingua franca. SQL is more of a patois.

> There
> is no other common (ANSI/ISO?) language for interacting with databases, is
> there? If so, what products support it?

The requester can look to any language that supports abstract data types for potential sample syntax. I would recommend a solid understanding of the fundamentals when comparing syntactic proposals, though.

> > > There are some situations, where navigation is useful. If the task you
have
> >
> > > to perform needs navigation, why should a DBMS (OO or R) hinder you ?
> >
> > No task requires navigation. Why should any dbms require it?
>
> That is a bold and omniscient claim. How do you propose to support it?

It's plainly true. How do you propose to contradict it?

> How does
> one prove that the universe of problems may be solved in precisely one
way?

I never made such a claim. I claimed that the universe of problems requiring precisely one way, ie. navigation, is empty.

> > > For example, how do you implement a topological sort with a RDBMS.
(Maybe
> > > there is a solution, but why should I hire a relational algebra pro,
if the
> >
> > > task is easy with navigation)
> >
> > You do not need an expert on RDBMS to implement a topological sort, you
need
> > an expert on graph theory.
>
> Substitute one expert for another and what have you proven? That the task
is
> still outside the reach of the average implementer who needs to solve it?

I have proven that the average implementer can gain sufficient expertise at the local library (if not from the implementer's own bookshelf.)

> > > - i am not derived from ClassX, but i can look like and act like ?
> >
> > If you look like and act like, you are derived from, or you are ClassX.
> > Remember physical independence!
>
> There is a significant difference between "I am of (derived from) Class X"
and
> "I can be converted to Type X (or I play one on TV)".

There is also a significant difference between "I can look like and act like" and "I can convert into". Received on Sat Oct 06 2001 - 19:26:23 CEST