Re: Date's First Great Blunder

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:cWgfc.267$c94.130_at_newssvr16.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c5jivl$8ca$1_at_news.netins.net...
> > > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > news:<c5ia56$t04$1_at_news.netins.net>...
> > OO, like relational database theory, does have religious followers, but
> I'm
> > guessing that most practitioners of each are more pragmatic than
dogmatic,
> > working to develop and maintain information systems. It "works" to
> specify
> > a "record" by way of an OO class and include persistence methods in the
> > class
>
> No, it doesn't. I don't know a single competent OO programmer who does
that.

OK. I'll yield to your expertise on that. I have examples in hand with such a pattern, and have done it myself (but am, admittedly a beginner Java coder), but have not done it with an RDBMS.

> At most, I'd generate such with XDoclet or another tool. Such techniques
> scale very poorly, especially when you have object graphs - does only the
> parent get "persistence methods", or the children too? There are many more
> flaws with this, but suffice it to say that no OO programmer (other than a
> beginner) would handle "persistence" this way.

I suspect, then, that is true if the data model is relational.

> > -- and that is what's "evident" to "the vast majority of the OO
> > coders", I suspect.
>
> Not a single one that I know.

OK, I'll yield on that -- I'm green.

> > > A class is a type and "object" is the mix and confusion of the
> > > "variable" and "value" concepts.
> >
> > Is a class a type or a definition of a type? A type, being a domain, is
a
> > set.
>
> That set also has a specification. And a type has operators too.

So does it "work for you" to consider a class to be the very same thing as a type?

> > A class is a specification where the set of all objects that can be
> > instantiated using that specification constitute the domain (or the set
> that
> > actually ARE instantiated, depending on your definition of domain).
>
> So a domain is only those objects that already exist? That makes little
> sense.

I agree, but there are folks who consider a domain (as in "domain of a function") to be those values that are definitely in a set that maps to some range. With databases, I'm sure the former is more common -- I just didn't want to split hairs on that def.

> How does a type differ from its specification? See "set intension" vs
> "set extension."

OK -- I'm not familiar with those terms.

> > > Metadata is data like any other data, and it should be represented in
> > > the form of relations.
> >
> > Or in the same for as other data, agreed. Code is metadata..
>
> About what?

The software "object" for which it is the specification.

> What data does it concern?

The data that is software.

> Another flaw in OO is its (usual)
> requirement that every bit of code be tied to one class, regardless of how
> many classes it concerns.

Given the amount of reuse in OO, I don't understand this angle. Can you give an example of this flaw?
--dawn Received on Wed Apr 14 2004 - 22:27:40 CEST