Re: The IDS, the EDS and the DBMS
Date: Fri, 10 Sep 2004 18:41:40 +0200
Message-ID: <4141d947$0$78279$e4fe514c_at_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 - 18:41:40 CEST