On 22 mei, 21:53, r... (AT) raampje (DOT) lan (Reinier Post) wrote:

And just to nitpick on the nitpicking : he wasn't talking of OO
_modeling_, he was talking of OO _programming_.

Did you mean to suggest that OO _programming_ systems hardly ever base
their operation upon OIDs ?

On 23 mei, 00:33, Clifford Heath <n... (AT) spam (DOT) please.net> wrote:

Does it have cans of cat food ?



I raise the issue because it is such a popular item in any discussion
concerning that overhauled OO notion of "identity".

And I'd like to draw attention to a business object that is extremely
similar in nature to the cans of cat food : bills of money.

100 dollar bills (and bills of just any quantity of currency unit in
any conceivable currency unit, in fact) are uniquely identified by
their serial number. However, they also have a property of being
"fungible", meaning, essentially, that "if you need 100 dollars,
whereever, whenever, for whatever reason, then _any_ 100 dollar bill
will do". Or, in other words, the identity of the bill you actually
use to pay is completely irrelevant.

Cans of cat food can be identified solely by their location in 3D
space. However, noone cares a fucking shit which particular can it
was that any customer took from the shelf. Or, iow, for cans of cat
food, identity doesn't matter either.

Now, typical OOP systems take identity as a foundational concept,
meaning no more and no less than that they are inappropriate to
address any problem where "identity really doesn't matter".

"Clifford Heath" <no (AT) spam (DOT) please.net> wrote

I'm sorry. I misunderstood.

Mr. Scott wrote:
....
I believe D&D say an OID is a pointer. If that's what those amount to
in the magical OO world, then you are arguing that relations should be
allowed to store pointers. This would contradict the Information
Principle and I'd say the whole relational idea would start to crumble.


Maybe you mean something else. Eg., I don't think D&D object to a
system that saves us effort by generating values so that we don't have
to make them up, but those would be generated values, not pointers. I
certainly would like that feature when trying to record a
third-greatfather about whom I might know only a non-unique surname.


It would be more accurate to distinguish the tag 'D&D' from the 'D or D'
writings. When it comes to their perhaps most referenced joint writing,
ie., TTM, the smaller part is about relational implementation, not
theory per se, then there are optional parts about 'OO' concepts. The
smaller part would be even smaller were it not for all the warnings
about what not to implement.

On 23 mei, 19:15, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
Not only do they "not object" to this, they even explicitly make such
a feature a "very strong suggestion".

Erwin wrote:

So was I, but thanks for the correction.

This is a matter of definition, but to me, an 'OID' is something
used in logic and databases, in programming the term is not used
as far as I'm aware. The difference between OID and reference is that
references arise naturally in programming, whereas OIDs are an emulation
of references that must be carefully constructed.

--
Reinier

paul c wrote:

I know the term OID only from some database literature, in which it is
used for such generated values. In OO programming, a distinction can
be made between pointers, which are addresses in memory and which can
be meaningfully added to, and references, which are not and on which
the only meaningful operation is equality comparison. References are
in between pointers and OIDs.

--
Reinier

Erwin wrote:

[...]

That conclusion is overly hasty. Nothing prevents me from representing
cat food as an 'amount of cat food' property to some object.

--
Reinier

On May 22, 3:09*am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
Algebraically all database constraints can be represented in either of
the three equivalent forms:

1. As relational identity.
2. As order constraint (generalized subset relation).
3. As comparison with DUM.

Proof is the following RL equivalences:

-- representing order via equality
x < y <-> x ^ y = x.
-- verse verso
x = y <-> x < y & y < x.
-- order via comparison with DUM
x < y <-> R00 = ((y' ^ x)` ^ x)`.
-- comparison with DUM is trivially an equality constraint

show that every order.

"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

It is my understanding that an OID is a system-generated name that is
assigned to an object, and that each OID is assigned to only one object. In
the OO world, OIDs are only assigned to instances of reference types. Maybe
that's why D&D erroneously call them pointers.

Suppose that you have a relation that records what you have in the cupboard,
{item, quantity}.
What is the difference between the following relations (assuming the closed
world assumption of course)?

{{item:"can of dog food", qty:3},{item:"can of cat food", qty:0}}

{{item:"can of dog food", qty:3}}

Both indicate that there are three cans of dog food, but does the second
indicate that there is no such thing as a can of cat food, or is it
synonymous with the first? Assuming that "can of dog food" and "can of cat
food" are members of the domain for attribute "item," they appear to be
synonymous, but how can that be? Under the closed world assumption, the
proposition that is the result of substituting the values "can of cat food"
and 0 for the variables in the predicate for the second relation is supposed
to be false because the tuple doesn't appear in the relation! And since the
propositions for every other possible "qty" are also false, one is forced to
conclude that there is no such thing as a can of cat food.

With object identifiers, each can of dog or cat food would have unique name,
like so:

{{id:23,item:"can of dog food"}{id:25,item:"can of dog
food"}{id:34,item:"can of dog food"}}

One can then determine the quantity by counting tuples. The question of
whether or not there is such a thing as cat food is answered by "can of cat
food" being in the domain for attribute "item."