Re: Databases as objects

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.

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.

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

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

  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!

> Inheritance is a mechanism for code reuse, and that's a good thing.

Code reuse is good. Yes. Inheritance? Not so good.

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

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

  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.

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.

  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.

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

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

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? Received on Fri Dec 22 2006 - 22:12:09 CET