Re: The Practical Benefits of the Relational Model

pkl_at_mailme.dk (Peter Koch Larsen) wrote in message news:<61c84197.0209162339.234cf270_at_posting.google.com>...

> I can hear a lot of advertising for Alphora which probably happens to
> be a good product and which - i know - is built around the Date/Darwen
> hypothetical D language. To be fair, however, you should not use the
> comparison with C++ ...

It certainly is not meant to be a comparison with C++ specifically. I am referring in general to OOP languages, of which C++ is (to a degree) a member.

> C++ was defined for systems programming and is defined with strict
> criteriae regarding compatibility with C as well as performance.

Fine, but irrelevant. I, am not arguing against existing languages, I am simply making a case for concepts that we can look for in future, high level languages.

> Let me respond to your specific criticism here:
> 1) Grey areas as to where to put a binary method.
> In practical life, these areas are not so grey at all. Very often, the
> answer is evident and in the few practical cases where they are not,
> C++ does provide you with the means ...

The situation I am referring to is in regards to "static" methods. Since you seem stuck on discussing C++, I will mention that this is rarely an issue in C++ because it is easy enough to place "binary methods" outside of either class. Even in C++, however, there are times when the decision is just plain arbitrary. Binary operator overloads for example. Does the times operator overload method that takes types A and B as arguments go in class A or B?!

Some languages that are even more OO force ALL otherwise global functions to be placed within a class. The decision of which class IS often arbitrary.

In addition, if it can be shown that the decision is arbitrary in even one case, then there is a problem with the fundamental concepts involved. I tire of the argument 'But I can work around the problem with X.' We are trying to SOLVE the problem.

> The hypothetical language D does support multimethods, but with a
> prize: grey areas otherwere. If you define operators
> OP(CIRCLE,ELLIPSE), OP(ELLIPSE,ELLIPSE) and OP(ELLIPSE,CIRCLE) the
> system is silent of which method that is called when you invoke it
> with two circle-parameters.

I don't think you understand D's type inheritance very well. I can sympathize, because it took me a while too. The point is that ANY "override" of an operator (such as OP(C,E)) MUST preserve the same semantics, so the choice is not a logical one. The implementation can decide the best path, possibly even an additional optimization point. In fact, all such overrides are conceptually unnecessary, they merely provide for optimization.

> C++ is defined very precisely and to force
> a solution on a problem such as above into a (ISO) standard would
> really be detrimental in many aspects.

C++ HAS to define them, because the semantics can change.

> 2) Method/property:
> There is no such thing as a property in C++. If you are referring to
> C# or some extension of the C++ language (which I believe you might
> be), it is true that you have a freedom of choice. Anyway, i do not
> see why this freedom should be a minus. In D you certainly also have
> these kind of choices.

In this case, as you guessed, I am referring to languages that have "properties." There are actually some pretty good reasons to draw a formal line between properties and get/set functions. (See "possible representations" in The Third Manifesto book).

> 3) V-tables:
> I should mention that there is no such thing as a V-table in C++. The
> standard describes a model, not an implementation.

What I should have stated is that virtual method invocation follows class definitions, not functions. It is desirable to allow for the definition of "virtual" functions "outside" of the type definition. I know the justification for "encapsulation" and "member hiding", but after years of practicing it, I don't buy it. Hiding can be replaced by integrity constraints. Encapsulation is only a conceptual thing having to do with perspective. This concept can be replaced by "views" and adequate developer tools.

My preceding comments are very informal, but because OO concepts are also not formal, I think I am allowed to discuss them using the expected vague generalities. ;-)  

> 4) Furthermore I do not consider the relational model well defined -
> and certainly not in "The Third Manifesto".

Please see Chris Date's reply to the posing from Costin Cozianu. How can you claim to have read The Third Manifesto book and then say the relational model is not "well defined"?! If you have a beef with it, step up with a REAL arguments, not just arrogant claims.

> > -Specialization by Constraint and Generalization by Constraint. In
> > English this means that I can treat an ellipse as a circle if the
> > ellipse 'really is' as circle.
>
> I must admit that this "Specialization by Constraint" stuff makes me a
> little nervous.

It made me nervous too until it finally clicked. Once it did, I couldn't imagine looking at things any other way.

> How well thought of is this model? As a hint let me
> just ask you these questions:
> 1) Is RATIONAL a SUPERTYPE of INTEGER?

Yes.

> If yes, is there then
> a difference in physical representation for these two types?

There could be. That is up to the implementation.

> 2) How do you perform integer division? How do you perform RATIONAL
> division?

Those are semantically distinct operators and they should be defined as such.

> 3) If you declare a type COMPLEX, can you then declare it a SUPERTYPE
> of RATIONAL? If no, why? If yes how is the physical representation?

Conceptually yes. In fact, you could look at each new type as suddenly becoming yet another direct or indirect supertype of Omega. Physical representation is up to the implementation.

> I do not quite understand the term "implicit references [...] of any
> expression". Could you please explain?

Sure. Table A references (has a FK to) table T. When I have a query or view based on "A join B" (B is another table), it is possible to infer that the query or view implicitly references table T. This is a very powerful byproduct of logical data independence and forms the basis of our product's ability to derive complete user interfaces.

> > ... Well defined inheritance is beneficial because the SYSTEM can
> > help us enforce domain constraints and such.
> I do not see the connection here. Surely it must be possible to
> enforce constraints even if type inheritance is not used. Constraint
> enforcement is even possible (and easy!) in C++ - whether you use
> inheritance or not.

I am referring to declarative constraint enforcement (with it's accompanying benefits). What I was (obviously poorly) describing is the idea that the system can participate in the enforcement of semantics involving inheritance.

> > -User defined types (OOP encourages the practice)
> Ahh - you must explain where user defined types then originated.

C'mon, user defined types existed before computers did... when types were first discussed in the context of logic systems.

> > -Type inheritance.
> > OO is is not a "model" and is certainly not a data management solution.

> What about generic programming.

What about it? Are you suggesting that "generic programming" is some kind of formal model or is a data management solution?

> This "OO is not a model" is often heard. However, in all the
> litterature that i have read about relational systems (including a few
> of Mr Date!), I have not seen ONE reference to a mathematical
> text-book or similar that is supposed to describe the relational
> model.

The Third Manifesto book itself includes a formal definition of the model and includes the necessary references.

> Sure, relational systems are based upon set theory, but this
> alone does not in my opinion warrant all these model-claims. For one
> thing, the relational model has not considered the implications that
> computers are finite (and thus that precision is) very much.

[sigh] It is not the role of a formal model to "consider the implications that computers are finite." This is the job of an implementation. Let's be clear: the relational model is a conceptual model, not some implementation prescription.

> As for the model in "The Third Manifesto", I do not consider it a
> model at all. It is a very rough sketch, where much detail is left out
> and justifications for the prescriptions (and proscriptions) have no
> or little theoretical foundation. The model of inheritance is just one
> such place!

If you are going to make such presumptuous claims, I hope you can back them up. You are throwing out words, but I have yet to see a substantial argument. What aspects are "sketchy"? What justifications are missing? What is missing a theoretical foundation?

> That said, I must hasten to add that I do like the relational model
> very much and that i agree with you on most of your other points. We
> just should not jump on the "third manifesto" waggon without a far
> more careful study of the implications of that model.

Let me just tell a little of our story: We were working on application development tools and having a tough time generalizing many aspects. The Third Manifesto was among our research materials, and we were quite skeptical of it. We certainly didn't initially set out to implement TTM. Many of it's core concepts seemed to solve problems we had so we started by implementing them. We discovered as we continued, that Date & Darwen had created nothing short of THE RECIPE for creating the ultimate DBMS. In fact, every time that we deviated from their recipe, we soon discovered the wisdom in the aspect of their specification from which we had deviated. We are still non-conforming in a few areas, but those areas happen to be problems in our system and we plan on correcting them. The bottom line: we were skeptical, we tried it, it works!  

> I have read elsewhere that you can provide us with a pointer to the
> Alphora documentation. I would be very happy if you could provide me
> with a copy to.

I will post it in this group as soon as we have it available on our site.

Regards,

--
Nathan Allan