Re: Databases as objects

On Dec 22, 1:12 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Marshall wrote:
> > On Dec 22, 9:58 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
> >>Presumably, unlike many OO proponents, Parnas thinks not all ideas in OO
> >>are good ideas.
>
> > The funny thing is, I actually like OO, such as it is. Java is a better
> > language than I otherwise would get to use.
>
> > I think it's worthwhile to identify what exactly the good ideas
> > in OO are.
> > I would propose the classic troika:
>
> > inheritance
>
> Eww! Yuck! What's good about inheritance? Reuse is good. Inheritance has
> to be the worst way ever proposed to achieve reuse, though. Generics
> provide greater reuse without introducing inappropriate coupling.

My message should be read as an explanation of the evolution of my thoughts on OOP. There was a time when I thought "inheritance, encapsulation, polymorphism" was a tremendous achievement. Nowadays I see better abstractions. Fortran is a big step up from assembly, and that fact doesn't change when we introduce SML and observe that SML is a big step up from Fortran. If one is interested in programming language theory (PLT) then it behooves one to understand exactly what Fortran brought to the table, so that even though one does not wish to use Fortran any longer, one does not accidently discard some of its benefits when one is moving on to the next higher level.

Inheritance has value. Consider that if one were given a choice between a fairly primitive language that did not support it and an otherwise identical language that did, I would choose the language with inheritance. The fact that we now understand that inheritance has problems and limitations that better mechanisms don't have doesn't change the fact that inheritance is better than nothing.

Does the idealized language I have in my head have direct support for inheritance? No it does not. But I still ... honor it the way I honor the invention of Fortran. That I do so may appear somewhat perverse in light of how many people still think OO is the way, the truth, and the light. But I would be as much mistaken to take a reactionary position against them as I would be to join them. I aspire to a deeper, more nuanced understanding.

> > encapsulation
> That depends on what one means by encapsulation.
>
> > polymorphism
> Again, I suppose that depends one what one means by polymorphism.
> Quite a few things count as polymorphic in my view.

Sure. The interesting one seems to me to be parametric polymorphism.

Natural join for example is delightfully polymorphic. It takes two operands of the abstract type called "relation" regardless of what the concrete type of those relations are. One also wants a mechanism to write such operators oneself.

> > Now it turns out that "encapsulation" has two related, widely
> > used meanings: information hiding, and scoping together functions
> > and the data they operate on, which I don't have a good name
> > for besides "encapsulation."
>
> Information hiding is good. Scoping together functions and data does
> exactly the opposite of information hiding by introducing an arbitrary
> design decision the user is forced to contend with.
>
> Take the classic example of a hiring function. Does that scope with the
> employer or with the employee? Either, neither and both are all equally
> arguable in my mind.

Sure. In fact this strikes me as the usual many-to-many case, which relational handles so well and OO doesn't.

But again, this is another case where it seems to me a step was taken to solve a real problem. The solution isn't the right one, but it did solve some problems.

The better solution I think is some kind of module system, perhaps like SML modules or Haskell typeclasses. In any event this sort of modularity question is not one I understand at all deeply.

> > And there
> > are many kinds of polymorphism, but only one is emphasized in OO. So
> > the list becomes:
>
> > inheritance
> Yuck!
>
> > information hiding
> Yum!
>
> > encapsulation
> Ugh!
>
> > subtyping polymorphism
> Tasty!

While subtyping polymorphism is the best of the list, I still think it's not the ideal solution. In fact, for all the convenience of subtyping, I've decided it's largely to be avoided. It's something you sort of have to have if you're stuck with a nominal type system, but these days I feel nominalism is best kept to a minimum.

Amusingly, I see relational projection as a more general mechanism. If we want to construct a supertype instance from a subtype, simply project only those parts that one wishes to keep. Is-a colored point a point? Is-a it a color? I think "is-a" is the wrong question! I can get a color and a point out of a colored point with simple projection. I can get three different 2D points from a 3D point with projection. Etc. You can do this with easily with a structural type system, but not with a nominal one.

> > Inheritance is a mechanism for code reuse, and that's a good thing.
> Code reuse is good. Yes. Inheritance? Not so good.

Again, I think inheritance is worth looking at to see what works and what doesn't work about it, but not as an example of something that was "done right."

Consider the Template pattern. An abstract base class with a variety of final methods, parameterized by a small number of abstract protected methods. Each derived class fills in only the abstract methods. I find it is often the case that the majority of the code can go in the base class, and I get a fair degree of reuse thereby.

Now, I think there are higher-order functional techniques that achieve the same thing in a better way, but I still consider the template pattern a success.

> > It is however a somewhat brittle mechanism, and over time the
> > OO consensus has been moving away from inheritance.
> That's a good thing. Eventually, they will invent relations.

Ha ha! No doubt. And they will probably call it something like "extreme collections."

> > Information hiding in the OO sense is a good idea because it permits
> > limiting the scope of updates, which allows some centralization in
> > the manual enforcement of data integrity.
> I disagree. Information hiding necessarily hides the locus of effect.
> Limiting the locus of effect is a different design goal that sometimes
> conflicts with information hiding.

I can't say I particularly understood that.

> > Once a field is private,
> > it can only be modified within a single class, and so you only have
> > one class's worth of code to look at to see all the ways that
> > field can be modified. However, a distinctly superior mechanism
> > exists in the form of declarative integrity constraints. The reason
> > this is superior is that being declarative rather than procedural,
> > it is easier to get right: you only have to state what must not
> > happen, rather than think of all the ways and all the places that
> > might happen.
>
> I am not sure I follow you here. When declarative, the only difference
> between stating what must happen or what must not happen is simply the
> negation operator. From a security perspective, it is generally better
> to state what is allowed than try to think up all the things one must
> prohibit. Constraints generally must evaluate to true.

My use of the negative in the above was a mistake.

We can consider three points in a continuum of integrity protection for a given variable.
1) any code any where has access and can modify it (traditional) 2) the variable is private to a given class and only the code

    in that class can modify it (oo)
3) the variable exists inside a managed container of some kind

   that support declarative integrity constraints. (declarative)

Points 1 and 3 represent the endpoints of this continuum.

Consider some arbitrary constraint f on x.

In case 1, at each and every update site in all application code, when modifying x, we have to calculate a new_x, check f(new_x), and abort the modify if it is false. When writing future code, we have to know this, and maintain this discipline.

In case 2, the scope of application code for which we need to manually insert the checks is limited to the class in which x is a private field, and when writing future code, the scope is likewise limited.

In case 3, application code doesn't have to do anything, now or in the future.

My point is:

   1 < 2 < 3

As an aside:

Many of the bogus claims of the OO crowd against SQL stem from confusing cases 1 and 3. If the only equation you know is

   1 < 2

and 3 looks like 1 to you, you're going to come in here and start proposing unfortunate things like saying the database is a variable that should be encapsulated so that application code has no direct access.

> Declarative is superior because it effectively separates concerns. And
> by 'separation of concerns', I refer to Dijkstra's austere mental
> discipline and not to the trite buzzword the aspect-oriented idiots
> would make it.
>
> When one knows what one wants, it is easier and less error-prone to
> state what one wants than it is to state how to achieve it.

Just so. This to me is one of the few areas of PLT where The Right Answer is pretty clear and well understood. By a few folks, anyway.

> > Once you have declarative integrity constraints,
> > the whole concept of public vs. private seems quaint. However,
> > until you've figured this out, SQL looks like it's moving backwards
> > because it doesn't have private.
>
> SQL's lack of support for data types makes it backward. Separating data
> type from possible representation makes public vs. private seem quaint.

Absolutely.

> > I have nothing much to say about bundling types and methods.
> I will give you the benefit of the doubt and assume you have nothing
> good to say about it.

Just so.

> > Now, polymorphism is simply great. However subtyping is
> > perhaps the least interesting kind of polymorphism, with
> > parametric polymorphism being more powerful and general.Indeed.
>
> > Interfaces in Java are quite useful, however a number
> > of authors have commented on its limitations. Notably
> > the lack of retroactive abstraction mechanisms. I think
> > this can be particularly well addressed by the use of
> > a structural type system such as SQL has, rather than
> > a nominal one such as most OO languages have. (OCaml
> > being I believe the notable counterexample.) This
> > also gets in to all kinds of issues around union types
> > that I'm still thinking about.
>
> > Anyway, just some thoughts.
> So much to learn about and so little time.

Alas.

> Speaking of which, does anybody know of any good online references that
> teach useful statistics? As opposed to the useless crap they teach
> undergraduate engineers?

I can ask around. I know some statisticians.

Marshall Received on Sat Dec 23 2006 - 00:41:37 CET