Re: The IDS, the EDS and the DBMS

Marshall Spight wrote:

> mAsterdam wrote:

>>Marshall Spight wrote:

> I still very much like OO *and* I like RM.

Same here.

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

Of course there is. Development teams need some folklore in order to be able to
communicate ideas *before* they
are well-defined. Some of the OO framework serves very well as basis for this folklore. Some (methodologists, language designers, preachers) take it all way to serious to be practical and work out generic consequences - and you know what? Some of their thinking even makes sense, and after a while their results get accepted and added to the folklore.

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

Don't read to much into it.
Just try, as an excersize, to model genealogy, let's say for a distributed database for cooperating genealogists.

Looks simple, no? A few month ago I looked at some genealogy sites, and (just for fun) I tried to understand the models behind it.
I was astonished by the vast number of seemingly arbitrary but consequential choices one has to make before you can have a working model. E.g. What is a date?

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

Sorry for putting you on the wrong foot. But while we are at it: Multiple inheritance is essential in the initial thinking about any system. Support for it in a programming language is quite another issue. If it's there, nice, but at some point or another somebody *has* to make inheritance disambiguating choices.

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

Is encapsulation a mechanism? The building of the capsule, maybe. I think (ok that's somewhat redundant) it is a useful technique to hide distracting features, requiring a concious decision: what to expose and what to hide. Table definitions are all exposed by default.

>>>What is needed, then, is not a "mapping" from one to >>>the other, but rather a *unification.* Received on Wed Sep 08 2004 - 00:17:45 CEST