Re: Conceptual, Logical, and Physical views of data

dawn wrote:
> Marshall Spight wrote:
>
> > The single most telling distinction between an address
>
> do you mean "pointer" here?

Yes. But, ACK! I made a terrible, meaning-reversing typo in that paragraph. Let me put it right:

> The single most telling distinction between an address/pointer
> and a foreign key is this: in a system with ***pointers***,
> you have to have a special operator that given an address
> returns its referent, and an inverse special operator that
> given a referent returns its address. With content-based
> addressing, there simply is no such operator; the comparable
> functionality is available already just from being able to
> address data via its content.

> Does this include all key-value approaches?

I'm hesitant to answer. Since you asked that question in an earlier thread, it's made me think about the canonical key-value case, a la java.util.Map. And it's kind of a weird case: on the one hand, it's sorta content-addressing, in that you can address a value pair according to the content of the key. On the other hand, it's not *generally* content addressable; the get() operator is a lot like the pointer-dereference; and the values and keys support quite different operations. So I'm on the fence right now.

> > Also: the pointer is *external* to the data referred to,
> > whereas the foreign key is integral to the data.
>
> OK. So, we could talk about a web page as a (URL, HTML) pair and the
> HTML might include a foreign key value for another (URL, HTML) pair.
> This would be compared to a model where you have (WEBRESOURCE) and
> WEBRESOURCE=(U,H,A,B,C) where U is a candidate key and B is a foreign
> key to WEBRESOURCE.
>
> Am I close?
>
> > Have you ever programmed in C or C++? (Non-rhetorical question.)
>
> Not that I would admit.

Mr. Kennedy, you haven't missed a thing. (Well, maybe templates.) But for the purposes of the discussion, that's unfortunate, because the reference/dereference operators are excruciatingly obvious in those languages.

> > You know the * and & operators? That's them.
>
> I know the latter if it is the "bitwise and" but not the *.

'&' also means bitwise and, but that's not the one I mean. In C, if you have a pointer value, you put * in front of it to get the thing it points to. If you have a thing, you put & in front of it to get its pointer. Note that these operators aren't good for anything else. (Please ignore the overloading issue; I don't mean to say those *characters* don't have multiple meanings.)

> > (In Java, the situation is obscured by the fact that both operators
> > are made implicit; there's no syntax for them. In Java, when
> > you mention a pointer, the only thing you could mean is its
> > referent, so the dereference operator is automatic.
>
> OK, this is where I'm missing something. I need to understand
> "dereference operator" for one thing. Usually if someone says
> "pointer" in Java, after the booing stops, they likely mean "reference"
> to an object, right?

Yes, exactly. A Java reference is a pointer. A nicer, cleaner, *safer* pointer than the C pointer, but a pointer nonetheless. In Java, can't do *anything* with a pointer *except* dereference it (unlike C) so they make the dereferencing implicit. There's so special character you type. Every time you see an appearance of a reference in Java, it's automagically dereferenced. Likewise, the only way you cat get a pointer is when you construct an object, so the "new" machinery in Java implicitly applies the reference operator. This extensive implicitness, while quite a nice usability feature, dramatically obscures the pointers-nature of Java references.

> good to know you have a social life.

We spent the evening with two other adults. We talked about sailing, art, and their upcoming vacation. No one asked me to play Pokemon all evening.

> Clijsters just won the US Open,

Uh, is that tennis? Golf? "Clijsters" to me has the ring of an adopted stray cat's name.

> so I'm going back to grading.

What's the subject these days?

Marshall Received on Sun Sep 11 2005 - 07:48:36 CEST