Re: The IDS, the EDS and the DBMS

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:413ced7c$0$566$e4fe514c_at_news.xs4all.nl...
> Marshall Spight wrote:
>
> > Perhaps; perhaps not. Please remember that in my case, "us"
> > is the OO camp. I have been a professional OO programmer
> > for 19 years, and only began learning about relational 8 years
> > ago.
>
> Ever smoked a cigarette in the vicinity of a converted smoker?

That is a fair point, but I'm still going to claim it's not directly applicable. I haven't forsaken OO the way a non-smoker has forsaken smoking. I still very much like OO *and* I like RM.

> Heh. I've never understood OO as anything else but: one way of
> accomplishing modularization. By viewing a certain compound
> of (passive) data and (active) behaviou?r (an 'object' or 'actor')
> as a collaborating, responsible unit, this shared (by the design
> team) metaphore helps organizing the code in modules...

Yes, exactly. But I don't fully understand the boundaries and implications of this yet. There may be more still going on.

> > Inheritance is interesting and underrated. It has its dangers,
> > but I think these are mostly because the kinks haven't been
> > worked out yet; as a result, I feel that it has something
> > of a bad rep that is not deserved.
>
> Try understanding genealogy. Very reveiling.

I'm not sure I understand you comment. If you are referencing multiple inheritance, then I still claim it's just that the kinks haven't been worked out yet. Also consider languages like Eiffel which have explicitly taken on the MI issues and addressed them directly, unlike C++, which tries to shield its eyes, and Java, which gives up on the problem as too hard.

> > Encapsulation is absolutely necessary for OO languages,
> > but I think ultimately, it will be discarded. Encapsulation
> > is something you need when you don't have declarative
> > integrity constraints; if you had them, you wouldn't
> > need encapsulation. (This is probably a controversial
> > position.)
>
> Encapsulation is never absolute to everyone.
> If you need to get under the hood, you'll
> have to be able to break the black-box seal.

Right. This is why I believe it will be replaced with better mechanisms. Consider what one uses encapsulation for: to enforce certain invariants in data structures. Isn't declarative integrity constraints a uniformly superior mechanism for doing that? If there is more to encapsulation than enforcing integrity, I'm not aware of it.

> > What is needed, then, is not a "mapping" from one to
> > the other, but rather a *unification.*
>
> Sharp! :-)

Thanks!

Marshall Received on Tue Sep 07 2004 - 17:50:59 CEST