Re: Objects and Relations

On Feb 11, 10:57 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> On Feb 10, 1:23 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
> > On Feb 10, 12:25 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:

[snip]

I've really lost interest in this, but unfortunately I feel compelled to say a few more words because you have trivialised my argument. Perhaps I'm a junky.

My conjecture is far more subtle than you realise.

> > 3. RM is inherently about recording knowledge about entities outside
> > the abstract machine in the form of ground facts or propositions.
>
> Absolutely not - this is wholly incorrect. The principles of
> Relationaly /Theory/ could equally be applied to recording
> propositions about external 'entities' such as employees, just as it
> can record propositions about the current state of such things as a
> vector of TCP/UDP/etc sockets and the dynamic pool of pthreads
> handling them. Relational Theory is about recording statements of
> fact, whatever they concern.

RM can of course state facts about anything. The question is should it?

It seems entirely immoral to see a set of relations that taken together state facts about both internal and external entities. It seems quite wrong to mix these levels of abstraction. For example, what is a problem domain expert going to think of a query result containing "labels" of parts of the abstract machine (eg StringIds) that they don't know about and don't care about? I claim that strings should normally only appear in the data model as *value* types. A problem domain expert doesn't generally consider strings to have identity so therefore giving them identity in the data model is harmful. Furthermore, I conjecture that mixing facts about external entities and internal entities doesn't offer any computational advantages for the processing of data about the external entities when using a rich set of ADTs for attribute values (needed to keep the identity of internal entities out of the relational model).

So is it useful to use RM solely for internal entities? Most of the time it's not necessary for a machine to store facts about itself (ie its parts). It just "is". However Prolog shows that it can indeed be useful to build an abstract machine that is *directly* based on logic. Perhaps RM is useful. I have yet to see a compelling example.

I have written a middleware layer using a thread pool to handle incoming messages from multiple sockets and simple data structures like queues, lists, or maps do the job well. This is the kind of problem that a low level language like C++ is well suited for. However I'm prepared to keep an open mind on the use of RM for systems programming.

[snip]

> 2) I believe you are making crucial mistake in trying to compare data-
> oriented and process-oriented mechanisms. Apples with oranges - there
> is no applicable comparison to be made here. Perhaps if you limited
> this to structs vs relations there might be some basis of discussion.

RM+RA provides some process-oriented mechanisms. If you provide a hybrid language to make it Turing complete then you have equivalent computational power to OO but with an emphasis on RM.

OO can be used to merely represent state (without interesting behaviour) using get/set methods. ie it can be used as a dataoriented  mechanism.

Your argument is similar to the fallacy of applying the conjecture to itself to deduce that it is worthless because it implies that OO and RM have non-overlapping scope!

I regard my conjecture as a concise *explanation* for the "apples and oranges". It explains it with respect to the boundary separating the inside and outside of the abstract machine. Your so-called explanation is no explanation at all because amongst other things you haven't stated why OO can't (or shouldn't) be used for data-oriented mechanisms. You also will need to explain why RM+RA isn't an excellent basis for process-oriented mechanisms.

As it turns out, simple structs can be quite useful in OO programs, and processing of relations using RA is very useful on a RM. This makes me doubt your explanation for the "apples and oranges". Received on Sun Feb 11 2007 - 19:51:16 CET