Re: The IDS, the EDS and the DBMS

"erk" <eric.kaun_at_pnc.com> wrote in message news:e4582e65b0b658bca93af5e25b104de7_at_localhost.talkaboutdatabases.com...

> Yes, you're entirely right - I wasn't clear here. I'd say rather that
> languages like Java lack any structure other than the class (and package,
> which is mostly a good idea but we'll leave that out for now). As such,
> you have to "implement" other concepts in O-O form, leading to nonsense.

You are right. The consistent problem I've had with OO philosophy is that they think concepts don't exist until they are "invented" within the OO paradigm. For, example, Java "invented" automatic garbage collection, a mere 40 years after McCarthy invented the same thing.

It reminds me of the joke about the diverse group of new arrivals being given the tour of heaven.
I'll skip the joke. The punch line is: "Sh! Sh! They don't know any of the rest of us are here!"

>
> It would be just as bad if all you had were relations and primitives, with
> no useful ability to define types. Implementing a type as a relation would
> expose implementation... you have that now in SQL, which has bizarre and
> inconsistent type definition facilities (and the vendors have even more
> bizarre extensions of their own - my experience is with Oracle 6-10, which
> make me shudder).

Absolutely! When I moved over from DEC Rdb to Oracle, the first thing I noticed was the glaring omission
of "CREATE DOMAIN". That capability had been in Rdb since version 1 of the product.

I know, "CREATE DOMAIN" is less than type definition, but it's a useful step when it's used right. But then, to extend my earlier thought, bad domain definition can be worse than no domain definition. I saw plenty of that in DEC Rdb databases.

>
> In short, it's the square peg - round hole metaphor.

It's worse than that. It's the square peg - round hole metaphor, combined with the kid with a hammer metaphor.

> True enough - I just think we need more than one lever. There will still
> be hard choices to make in any design.

Excellent!

I think one of the reasons there are hard choices is that there are so many choices.

Back when I taught design, the hardest concept to get across at the outset was this: for any challenging design problem there will be more than one satisfactory solution.

Programmers tend to learn that there is one "right" solution, and a bunch of defective approximations to that solution.

> Understood, and it is what you claim. But "statics" don't make sense in
> the object world - they're functions that shouldn't necessarily have to be
> linked to a class. It's a clumsy use of classes, I think. But in Java you
> have no choice - those functions have to be somewhere.

Agreed.

>
> Also in Java, those statics severely limit your flexibility - if I have a
> piece of code using "MyUtils.someDamnStatic(String x)", I can never ever
> substitute another function - I have to change the implementation IN
> MYUTILS. It's a pain for growth and reimplementation. Thus the reason we
> end up writing wrappers around wrappers around wrappers - to avoid some of
> those problems. It's a lot of work which could be avoided if Java had a
> decent, manageable way of controlling instantiation.

> There are some similarities, but notice how despite the existence of
> various models like the above, in various O-O methods, how
> poorly-represented they are in most languages. Or at best, a language
> might do one of them, but offer no place for the others.

> Transmission is probably the last one that will be usefully formalized (if
> it hasn't already), but the word "process" is troubling. Most "processing"
> is either function application or enforcement of constraints, both done
> better declaratively than procedurally (though I realize the need for
> "glue" code which in many cases will be procedural - e.g. scripting).
> "Storage" becomes difficult when you're attempting to store things that
> are hybrids of data and behavior.
>

I'm not sure I agree. Transmission is the one I understand the least, but I think it's quite formalized at layers
below the layers I usually work in. In particular, the Shannon formula for information content is used way down at the level that processes signals picked up by a magnetic head. I've also used it in guessing game programs, but that's another thread.

Transmission also more nearly formalizes the distinction between "content" and "conveyance". (The USPO will deliver the porn in a plain brown wrapper, as long as it has the proper postage and the proper label. Same thing in networks.) But this distinction gets awfully confused when people start talking about a DBMS as being the custodian of the data. Unnecessarily confused, in my view.

> No, you're right, but once you've defined a type, and ways of referring to
> them, and the operations... you still need to be able to make assertions
> about the relations that bind them, and an object network (at least as
> represented by most languages) is a poor way to do most of it.

Why do objects have to be linked in a network? Received on Fri Sep 10 2004 - 16:08:20 CEST