On 25 mei, 23:04, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:
A reference type has the property of being a (set of all possible)
reference(s), and nothing more than that.
A reference (value) has the property of being useful ONLY if a
dereferencing operator can be applied to it, in order to get to the
referenced content that actually means something.
That is the same property that is also a property of pointers.
And that is why D&D _CORRECTLY_ call them "pointers".



Relations don't record anything. Relation _variables_ do. Speak
precisely or shut up.



Well, if you do not provide the exact predicate of the relation
_VARIABLES_ that you have in mind, then it would be pretty hard to
tell for anyone whether propositions derived from them are synonymous
or not, no ?



You claim that without giving the precise predicate that you have in
mind.

If the predicate is "The shop sells product <x> and the current
quantity available is <y>", then it makes PERFECT SENSE for a tuple
{"can of cat food", 0} to appear in that relation _VARIABLE_.

Erwin wrote:
Nice answers, thanks. The predicates were indeed missing, but I wanted
to add that trying to record 'negative' facts (if that was what the
unspoken predicates involved) might lead to contradictions or at the
least very tricky interpretations.

"Erwin" <e.smout (AT) myonline (DOT) be> wrote

On 25 mei, 23:04, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:
<<QUOTE
A reference type has the property of being a (set of all possible)
reference(s), and nothing more than that.
DISAGREE: a reference type is any type that is not a value type.

<snip>

<<QUOTE
Relations don't record anything. Relation _variables_ do. Speak
precisely or shut up.
A relation is what has been recorded, so there is nothing wrong with
referring to what it records.

<<QUOTE
Well, if you do not provide the exact predicate of the relation
_VARIABLES_ that you have in mind, then it would be pretty hard to
tell for anyone whether propositions derived from them are synonymous
or not, no ?
It doesn't matter what the predicate is because the propositions in question
differ in form:

Pab /\ Pcd /\ ~(Pad \/ Pcb)

Pab /\ ~(Pad \/ Pcb \/ Pcd)

These are clearly NOT the same.

<<QUOTE
You claim that without giving the precise predicate that you have in
mind.
As I stated earlier, it doesn't matter what the predicate is. The form of
the proposition that is a consequence of applying the closed world
interpretation is different in each case regardless of what the actual
predicate is.

<<QUOTE
If the predicate is "The shop sells product <x> and the current
quantity available is <y>", then it makes PERFECT SENSE for a tuple
{"can of cat food", 0} to appear in that relation _VARIABLE_.
But there is the contradiction. It doesn't appear in the second relation but
the absence of it logically implies it: that doesn't make any sense.

On 26 mei, 03:46, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:
Interpreting the meaning of a relation can only be done when some
predicate is given to do that interpreting. Predicates are tied to
relation _variables_, not to relations. TABLE_DEE appearing as the
value for relvar THE_SHOP_IS_OPEN means something different than
TABLE_DEE appearing as the value for relvar THE_ALARM_IS_SET.

Saying that relations have meaning irrespective of some predicate
coming from some relvar, is a plain and simple admission of the fact
that you simply aren't getting it.



It depends on the predicate of the relvar that these relations might
appear for.

If the predicate of that relvar is "The shop sells <x>, and the
current quantity available/in stock is <y>", then the absence of any
tuple for "cans of cat food" implies that the shop simply does not
ever sell such a thing. Presence of a tuple for "cans of cat food"
with quantity zero, would imply that the shop does sell cans of cat
food, but that it currently cannot do so because the shop hasn't got
any in stock. Both meanings are quite different.

If the predicate is "The quantity currently available for product <x>
is <y>", then it is indeed true that propositions including the
quantity zero can just as well not be made. My understanding is that
you are trying to turn this into a deficiency of the relational
model. It is not. It is just a property of the number zero, and it
is just the logical meaning of any quantity being zero.

Same can be said of the kinds of predicate/proposition that I think
Paul was referring to : it is true that it is not true that my name is
John Doe". Artificially fabricated arguments involving the CWA
applied to such predicates are not a valid criticism of the relational
model.



I have demonstrated sufficiently why and how you are wrong.



There is no contradiction. At best, in a certain particular case
(which involves the _assumption_ that you have silently made about
what the predicate is), there is only semantic equivalence between
making an explicit statement about some quantity being zero, and
making no statement at all. Once again, that is not a deficiency of
the relational model, it isn't even a deficiency of any data model
what so ever, it is just a peculiar property of the number zero when
it is used to express quantities. Accounting software already
rejected bookings with a zero amount long before the concept of
databases (let alone relational ones) was invented.



As I cannot explain any better, I won't bother any further.

On 24 mei, 16:03, r... (AT) raampje (DOT) lan (Reinier Post) wrote:



I recognize the importance of the concept of "not using the actual
physical memory address as the means of identification of any
object". It gets in the way of memory managers that need to relocate
stuff.

So I recognize the concept that _inside_ an OO programming machine, it
is useful to have a kind of mapping table that acts as the sole point
of contact for any stuff that needs to access/wants to manipulate
actual physical addresses. I also recognize the concept of calling
the key in such a table a "reference" and the mapped value in such a
table a "pointer".

That said, and assuming that is also what you meant, and noting that
there can be several distinct references mapping to the same pointer
value,

I'd like you to explain to me what exactly the usefulness is of
"equality comparison of references", which I interpret to mean
"equality of the key value in said mapping table".

And I'd like you to explain to me how the dereferencing operator on
such a reference is totally unimportant. Which is indeed what is
implied by your claim that "the only meaningful operation is equality
comparison".

I say the only meaningful operation on reference types is
dereferencing.

"Erwin" <e.smout (AT) myonline (DOT) be> wrote

I didn't say anything about meaning. The predicate of the relation that
mentions cans of cat food is identical to the predicate of the relation that
doesn't. Under the closed world assumption, the FORM of the resultant
proposition for each given relation is different--regardless of what the
predicate means. Let me put it another way:

(Pab /\ Pcd /\ ~Pad /\ ~Pcb) /\ (Pab /\ ~Pad /\ ~Pcb /\ ~Pcd)

is LOGICALLY false. There is no need to analyze (assign meaning) because no
matter what P ultimately means, the expression is still false!

No, it doesn't!

<snip>

It is not the relational model that is deficient. The problem is that
quantities like the number of cans of cat food are in essence aggregate
values, and there are consequences to recording aggregate values in base
relations. I'm not saying it is necessarily wrong to do so, but I will say
that it is wrong to treat the absence of tuples with zero quantity as if
they were indeed present. That's just plain sloppy.

<snip>

Erwin wrote:

You are thinking in terms of a possible implementation.
It's more general and hence more useful to discuss this
from an algebraic point of view instead.

You are interpreting in terms of a possible implementation, but I am not.
I don't know if any tables are being kept anywhere.
I am merely saying that refererences, like OIDs, are a value domain
on which equality comparison is meaningful, but numerical interpretation
(e.g. greater than, addition and subtraction) is not. In some
OO languages object references do have this property, in others they
can still be treated as pointers in some circumstances, yet other
languages such as C++ depart from pointers and require strict
programming discipline to allow these pointers to be regarded
as references in this sence. This is why I say references are
(in practice) somewhere in between pointers and OIDs.

Hmmm ... yes, referencing and dereferencing is possible.
I meant to say that treating them as numbers or even as ordered is not.

But this certainly isn't true. It's important that we can tell the
difference betweenaliasing and copying of object values.

--
Reinier

On 27 mei, 01:15, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
Fair enough.

A reference value is a value from a domain called 'reference', and
there exists an operator DEREF that can be applied to reference
values.

What is the type of value returned by DEREF ?

And all the others questions and issues raised in the TTM section that
discusses variables of type POINTER_TO_CIRCLE and POINTER_TO_ELLIPSE.
(The word 'pointer' in those names really means 'references', not
'pointers' in the C sense). I cannot tell from here whether you've
read that, but if you haven't you might be interested, and if you
have, you might be interested to look at it again.



It's important (perhaps) inside an OO engine running programs, and
thus it is important for the OO languages concerned to have the needed
syntactical constructs to give the programmer the possibility to
control what will be happening inside said OO engine. At any rate,
none of this warrants the originally made claim that OIDs can be
useful in a database context.

Databases are collections of assertions of fact, not collections of
references to assertions of fact.

Erwin wrote:

<snip>

Well, they could be, but that would require adding complexity with no
offsetting gain.

"Erwin" <e.smout (AT) myonline (DOT) be> wrote


<snip>

D&D's argument against OIDs is based on a false premise. An OID is a name
that is assigned to an object in the domain of discourse, not to a program's
representation of the object. (See page 210 of TTM, Third Edition.) D&D
argue that an OID references a memory location (a variable), when in fact it
references what is represented therein.

<snip>