Re: The IDS, the EDS and the DBMS

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Fri, 10 Sep 2004 18:41:40 +0200
Message-ID: <4141d947$0$78279$e4fe514c@news.xs4all.nl>

erk wrote:

> mAsterdam wrote:

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

>
> Right, and some redundancy is the result of ill-chosen encapsulation: for
> example, a Java class with excessive accessors and various query-type
> methods that end up providing a poor cousin of relational expressions at
> much greater cost.
>
> A more odious example: accessors that provide direct access to internal
> representations, thus bleeding implementation and infusing the app with
> aliasing problems.
>

>>Capsules are one type of module.

>
> How do you define capsule?

Tough one. I'll improvise.
I must have been thinking of a modularityscale - designation/qualification: a "capsule" as a rather closed type of module. Examples: hardware modules: an IC is more on the capsule side than a circuitboard because there it is so much easier to alter it's behaviour by replacing or bypassing components. Software modules: An executable binary is a capsule, an interpreted language sourcefile is not (but could still very well be a module).

Makes sense?

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

>
> Meaning the concept of class gets watered down and abused, because you end
> up using classes for namespace, "global" functions, relations, and even
> first-class "function objects" (e.g. Strategy, Command). When your only
> structure is the class, and you need something else (which you will), you
> have to bend classes severely. That usually leads to strange hybrids as
> well, unless your team is very disciplined and understands these
> distinctions.
>
> Net result: objects that aren't O-O.

If you don't make cooperating strokes when swimming, you'll sink.
OO done sloppy or overzealous won't give you nice software. So will any other approach done sloppy or overzealous. Is there a more specific reason?

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

>
> I'm not sure it wasn't the other way around - features from older
> languages influencing the GoF to provide patterns that provide weaker
> languages with those features via patterns, which are structures without

Well, that's the idea of patterns: They are around us, waiting to be discovered. Surely others have solved similar problems in software construction or there wouldn't *be* patterns. Some of these solvers happened to be programming language designers.

 > patterns, which are structures without the structure.

I don't understand. Could you clarify please?

>>>...Type implementation; I think Date had it right in suggesting that type
>>>implementations could be done in a variety of languages, and even that
>>>those languages might be different than those used in the rest of the
>>>app... 
>>
>>Hmmm... but (at least the basic) types need not be
>>different, would they?
>>(They are, but that just raises the question: Why?)

>
> Not sure what you mean here - do you mean the implementation languages?
> Different from what?

 From eachother. Rephrase: why are the /basic/ types in different programming languages still different?

>>You joined the thread. What do you think of EDS/IDS ?

>
> Oh, you mean I have to actually stay on topic?

:-) Mostly just curious about your opinion on it. Received on Fri Sep 10 2004 - 11:41:40 CDT