Re: The Practical Benefits of the Relational Model

From: Peter Koch Larsen <pkl_at_mailme.dk>
Date: 26 Sep 2002 07:11:44 -0700
Message-ID: <61c84197.0209260611.6e61aeb9_at_posting.google.com>


nathan_at_alphora.com (Nathan Allan) wrote in message news:<fedf3d42.0209251103.77ec28c_at_posting.google.com>...
> 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.

The V-table remark indicated that you specifically had C++ (or a dialect) in mind.
>
> > 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.
But you _are_ arguing against existing languages and you do so in order to promote your future high-level language. I believe such criticism is okay, and I do not expect your criticism to be unbiased. I was just showing you (and others!) the other side of the coin. Perhaps this was an apple versus oranges comparison.
>
> > 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?!

Just to stick with C++, the tradition is to put operators outside both classes. The reason I stick to C++ is as mentioned that your attack did seem to be directed in that direction. Also, my expertise is in that language.
>
> 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.
Yes. Object orientation is just one of the paradigmas supported in C++.
>
> 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.
Yes. This is the approach taken by D: saying, that anything may happen and that it is up to the implementor (and any future implementor) to assure that semantics are preserved. This approach is most unsatisfactory from a software-engineering point of view.
>
> > 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.
But the semantics can change in D as well. One implementator implementing the AREA of CIRCLE might define pi as 3.14 (or use a system-provided constant), while another - defining AREA for ELLIPSE might define it as 22/7. Nothing in the D language (apart from the note that "semantics MUST be preserved) prevents this.
>
> > 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).

I see nothing but a thin syntactic layer here.
>
> > 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.

Yes. Implementable in C++. And there are libraries that makes this a breeze thanks in part to its template mechanism (the other side of the coin being that you have a run-time type query system).
> 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.

But D has taken hiding to its extreme in its type system. So I believe you are contradicting yourself?
The motivating factor behind information hiding is not to enforce integrity but to enforce an appropriate level of abstraction and to allow for changes in internal representation without affecting the users of the type in question.

>
> 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. ;-)
When you say "OO" here, do you mean "Other Orthogonal"? ;-) Joking aside, I do have to say that i disagree. While there may be many fuzzy Object-O books around, the same can be said of the relational ditto. And as soon as you turn to concrete implementations such as C++, you can find very concise definitions of a model.
>
> > 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.

I regard TTM as a very high-level description, vague in many places. Just search for the words "very loosely" in TTM. One such place is discussed elsewhere in this newsgroup, namely relational assignment. I would have hoped for (and expected) a more thorough discussion of this subject in TTM. Another vague and very central subject is that of view updateability: hardly discussed at all.

>
> > > -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.

This and the following questions were more pragmatic than you assumed. I was asking specifically about your implementation of the model. I hope you will take the time to answer them in that light. However - if the "Yes" above was meant to be representative for all D-languages, your answer differs from the one in the TTM (page 286 in the second edition).
>
> > If yes, is there then
> > a difference in physical representation for these two types?
>
> There could be. That is up to the implementation.

How is it handled in the Alphora product?

>
> > 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.
Again: How is it handled in the Alphora product? I am not sure that they are semantically different, but let us not persue this point further and agree that they are. The important thing is that they must be they must be syntactically different as well - and that is not to my liking. For one reason because of the ugliness of the resulting expression. You might end up writing k := INTEGER_DIVIDE(i,j) rather than k := i/j for integers and z := REAL_DIVIDE(x,y) for rational numbers. Another reason is that the type-implementors must be aware of any super-types and subtypes. This last example is better considered in the light of the COMPLEX/RATIONAL example. Here, SQRT might already be defined in the RATIONAL case and thus you can not use SQRT for the same operation with a COMPLEX parameter.
>
> > 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.

Why did the word "conceptually" creep in? Is it because it might actually not be so? In this case, the model has a problem.

>
> > 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.

But the D language JOIN uses the names of the columns to derive a JOIN. Thus foreign keys are not in any way taken into consideration.
>
> > > ... 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.

I am still confused. This should be possible even if another inheritance model is used, should it not? You would just have to declare (in that hypothetical language) that (e.g.) CIRCLE is a subtype of ELLIPSE.
>
> > > -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.
Okay - I just assumed we were discussing programming languages here. If your claim is that languages such as Pascal, COBOL or C is the starting point, my claim is that this was a very weak starting point indeed. Only structure was defined there. These systems were silent on such important matters as operators, creation and destruction.
>
> > > -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?

I meant that generic programming is one of the concepts that have evolved with object oriented system. I did forget LISP here, perhaps this way of programming should not be attributed solely to object oriented systems, but certainly it is C++ that has more than any made generic programming a solution for the masses.

>
> > 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.

I did look for references for "relational assignment" and "view updateability" in particular. For relational assignment i found nothing, for view updateability one that is out-of-date and needs revision.
>
> > 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.

Would it not be the model that should prescribe what should happen in situations such as the following:

R WHERE <cond_a> OR <cond_b>

Where there is an overflow in <cond_a> or in <cond_b>? Also, what should happen in this query should an error occur (such as a failing TREAT_DOWN_AS_.... operator)? It might be nitty-gritty for some, but not for the serious user of an actual system. And as a user of the D-language (e.g. as a member of the Alphora development team), these items WOULD interest me.
Apart from this, there is at least one place in TTM where an infinite memory model is implied - namely RM prescription 5. A hint? Consider a point which has a physical representation with cartesian coordinates. What happens in this (pseudo)code:
  POINT p (1.0,0.0);

  THE_ANGLE(p) := 45; (degrees assumed)?

My guess is that in an actual implementation, THE_LENGTH(p) would no longer be 1.0 and this violates the 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?

What I meant was that no or little justification is made for many of the pre- and proscriptions - at least not in TTM. Let me give you some examples here - all regarding "RM proscriptions" (chapter seven):

There are other places. One is OO VSS 1: Coercion (that is implicit type conversion) is not supported. (Page 234ff in the second edition). The the motivation is (quote pg. 235)"we do agree that prohibiting coercion ia a good idea anyway for a variety of other reasons - reasons that are widely understood in the programming languages community". There are no references to substantiate that claim. This explanation is very weak anyway, especially as they do allow numerous coercions - e.g. from CIRCLE to ELLIPSE.
>
> > 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!
If you have the time, it would be interesting for us to hear in which areas you did deviate and then return to the "proper way". I would like to know in which areas you are nonconforming, but this will probably be mentioned in the documentation mentioned below?

>
> > 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.

I will look forward to read it!
>
> Regards,

Kind regards
Peter Koch Larsen Received on Thu Sep 26 2002 - 16:11:44 CEST

Original text of this message