Re: The IDS, the EDS and the DBMS

erk wrote:

> I'm a latecomer to this thread (and most others at this point), but will
> jump in anyway.

Hi Eric, welcome back :-)

> Marshall Spight writes:
> mAsterdam wrote:
>

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

Just to make sure these assumptions aren't mine: modularization always comes at a price: one costfactor: supposedly non-visible, but nevertheless noticeably present redundancy (and there is more cost). Capsules are one type of module.

> O-O itself can be used in the sense of ADTs (the data-behavior coupling),
> but also, in most modern O-O languages, it is assumed to be an organizing
> principle for all development, not just types per se. That's where things
> get dicey. Any Java app I've ever seen has static public methods, often in
> a class with nothing but static public methods. What exactly is the value
> of O-O in that? In that case, the package and class name form a useful
> namespace; none of the other features of O-O do anything but detract from
> the structure.

So?

> Consider a very different paradigm: functional languages like Lisp. The
> power of its reuse is extraordinary, and yet encapsulation and objects are
> simply ignored (to a large degree). You can achieve much leverage and
> abstraction with no coupling of function and structure; in fact, the power
> comes from functions applied to arbitrary structures.
>
> Witness design patterns; how many of them simply go away in the presence
> of a properly-typed language like Haskell or ML? Don't patterns like
> Visitor and Strategy and Command cry out for functions to be treated as
> first-class language citizens? How many patterns are devoted to factory
> concepts (including Flyweight), belying the value of Java and C++-style
> "new" instantiation?

Some of the GOF-patterns have been
incorporated avant-la-lettre into
language designs. This should credit
both Gamma cum suis and the language designers.

> O-O has much to learn (mostly its place), and I think the "ultimate
> language" will use Third-Manifesto O-O concepts for types, relations for
> data manipulation, and first-class functions for... well, I'm not sure, or
> I'd have written the damned thing by now. But I think those 3 concepts are
> all critical to development.
>

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

Try prolog.

>>If there is more to encapsulation
>>than enforcing integrity, I'm not aware of it.

Hmmm... but (at least the basic) types need not be different, would they?
(They are, but that just raises the question: Why?)

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

You joined the thread. What do you think of EDS/IDS ? Received on Wed Sep 08 2004 - 01:55:41 CEST