On May 21, 1:38*pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
Thanks for the correction. Let me try again: it seemed to me that
Clifford's unary fact types correspond to propositional functions,
while his unary facts correspond to the propositions yielded by
instantiating such a type. As such, I see no real argument between
the models; in fact, the little I know of ORM (mostly from looking at
Halpin's page a while back) seemed to match up with the relational
model well.

On 21 mei, 12:41, Nilone <rea... (AT) gmail (DOT) com> wrote:
This is only true of read-only operators. Update operators are not
relations/functions, and read operators with side-effects are "still a
bit more" than just the relation/function on the arguments that
determines the return value.

If your aim is to "better understand OOP, and/or why it has the
problems it has", then you can't narrow down the discussion to just
read-only operators.



(a) There are probably hundreds of distinct ways to find
correspondences between this class and relational concepts. A tuple
of degree three with the attributes all being of type 'Man' and named
'Erwin', 'Nilone' and 'Bob', respectively, is one of them. And what
about this : a relation is a set. Where is the set in your class ?
How can I intersect that set with another one ?
(b) The fact that a certain class can be fabricated that may seem to
resemble a relation, does not warrant the conclusion that relation
corresponds to class (and vice-versa), in general.
(c) Wouldn't you agree that "static Man Erwin" is the declaration of a
variable named 'Erwin' which' type is 'Man' (making abstraction here
of the issue about pointers) ? Wouldn't you agree that " = new Man()"
is an assignment of a value of type Man (once again making abstraction
of the issue of 'pointer to Man') to that newly declared variable ?
Wouldn't you agree that all of this very very strongly points toward
'Man' being a _type_ ?



Yes, the RM is sufficiently complete to also be able to describe the
entire state history of a running program.



I disagree with "therefore". I do not see what kind of axiom makes
this a necessary consequence of the foregoing.

The fact of being able to use relations to describe/define (e.g.) the
existance of some variable in some running OO program, does not imply
that the programming constructs used in that running program also
"map" to the relational constructs used to describe it (and do so
universally). It should be a well-known fact that no single
relational structure is ever "THE" single unique possible solution to
any given modeling problem. That holds too if the modeling problem is
about running programs.

It feels to me like you're seriously mixing up distinct levels here.

Nilone wrote:

Hell no!

Erwin wrote:
It is amazing how much has been written about what Codd wrote compared
with the few dozen pages he described his approach. Also amazing how he
cut through the chaff only to see thousands of people try to
re-introduce it. Why are thousands of web pages recommended reading
instead of a handful of his short papers? What is it exactly that Codd
omitted that needs to be said? Who studies chess without playing it?


It's human nature to take refuge in taxonomies and dogmas of all kinds.
Opportunists see profit by inventing jargon to exploit that
weakness and the standard technique of evangelists is to overwhelm their
target victims (who are naturally lazy by reason of human nature) by
dictating vocabulary and enticing them with intricate thought frameworks
that pretend to be self-contained but are really quite insular, eg., in
the db field, the various 'modelling' rarely suggest a complete
implementation. As in theology, the meaning of belief is then distorted
to be the desire to believe, which becomes the product that is actually
sold. I'd say the question usually remains: where is the mechanical
leverage of any particular 'modelling' religion, eg., what is the point
of improved natural language expressiveness without accompanying machine
operators, as in 'how does a submarine swim'? Do any of them 'improve'
the lack of connection of ER and its ilk with implementation? A model
of beliefs is not the same as a model of a useable computer system. Why
do people persist in dodging the Information Principle? How can ORM
avoid sets without producing equivalents for the set operators? Do the
ORM proponents truly believe there is an advantage in postponing
implementation or is there just a vested interest in making systems more
complicated? The dozens of db's I worked on all had one problem in
common, the implementation of unnecessary requirements, nearly always
they were introduced by so-called domain experts and their programming
flunkies. Once in a while a powerful user would cancel them.

Nilone wrote:
Tell us why we need more 'correspondences'.

Cimode wrote:
Maybe. But the "objects" of object role modeling have nothing to do
with the object of the O-O crowd. The word object in ORM was derived
from linguistics, and in use before the term O-O was invented.

The only ones displaying the behaviour of the faithful here are those
who rubbish things they know nothing about.

paul c wrote:
Indeed. It has the potential to help people understand
the relational model better, and to implement it more
purely than has yet been done.

Because it does contain additional insight, for those
who are open to it. Few here though, it seems. They
refer to parade their partial knowledge instead.

But if you're not in that class, I dare you to at least
take a glance at some of the example models in ORM2 and
CQL on this page and honestly tell me you think there's
nothing interesting happening there:
<http://dataconstellation.com/ActiveFacts/examples/>
This stuff is pure relational, but at a level that anyone
can understand... and that makes a difference.

On May 21, 4:20*pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:
Sorry, Bob, I think that came out the wrong way. I meant a direct
description of OOP in a RM would require a domain called OID over
which we can define relations. In current SQL systems, I could use an
integer of the same width as the address bus. I certainly don't want
to change the RM in any way.

On May 21, 3:12 pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
We must include the host system in the model. During execution, the
DBMS / VM would derive the new state of the object from its variables
and methods, and update the tuple(s) that represent it in the
relvar(s) that describe the run-time state of the program.

The class defines the set. You can see the members right there. In
general, however, classes designate sets and subsets implicitly.
Classes with public constructor functions (and some classes without
them) define unbounded sets. However, I see it as one of the
weaknesses of OOP that I can't query the set of all instances of a
class. I could use a static private List or Dictionary to keep track
of instances, but that would interfere with the GC reclaiming the
object automatically.

Please don't ask me to map from the relational model to OOP. I can't
do so in general, since the RM has greater expressive power than OOP.
The greater system can describe the lesser, but not the other way
around.

I could write functions to determine intersections in specific cases,
but your question illustrates a general weakness of OOP. Although OOP
languages can't easily or generally query the objects in the memory of
programs, I still think a relational interpretation of the constructs
and mechanisms of OOP provide the best possible understanding of it.

All OOP classes describe set-like relations over a domain of objects.
I see no general relationship in the opposite direction. Perhaps I
used 'correspond' incorrectly, I had in mind a unidirectional
relationship. I took care to write that OOP classes 'correspond to'
relations, and not vice-versa. If I messed up the terminology again,
I apologize.

I don't disagree with you, but I don't see the need for the term
'type' yet. I imagine "Man Erwin" declares a relvar with a maximum
cardinality of 1, from the symbol Erwin to an element in the domain of
the Man class. A 'null value' corresponds to the empty relation. "=
new Man()" creates a new object in the domain of the class and updates
the relvar. I can imagine other implementations, e.g. a binary
relation for (symbol, class) and a relvar for (symbol, class, value).

Good, some common ground at last.

Would you agree that the RM can describe the entire possible state
space of any program?

I see, I used 'map' incorrectly. I had in mind that for every OO
model, there exists at least one corresponding RM model. Would you
agree with that?

The possibility always exists. I sometimes experience stubborn
misconceptions and flights of fancy. I'll try to keep my nuttiness
reasonable and well-mannered, and I appreciate any time and effort you
spend to read and respond to me.

Nilone wrote:

Sorry, Nilone, it's still sounds like a lousy idea to me.