Re: Date's First Great Blunder

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:407d5b68.12958493_at_news.wanadoo.es...
> On Wed, 14 Apr 2004 09:48:06 -0500, "Dawn M. Wolthuis"
> <dwolt_at_tincat-group.com> wrote:
>
> >> The vast majority of the OO coders reject the evident when it is
> >> against the dogma.
> >
> >OO, like relational database theory, does have religious followers
>
> I disagree. Relational database theory is a branch of maths and OO is
> a set of fuzzy and contradictory guidelines that lacks any consensus.
> It is clear that the second is a lot more religious followers prone.

Not to me, it isn't. Mathematical models are simply models/metaphores. The discipline of "doing" relational theory could be seen as mathematics, but the application of this mathematics to the discipline of application software development has to do with a belief that this mathematical model has something to do with the engineering effort underway.

> >, but I'm
> >guessing that most practitioners of each are more pragmatic than
dogmatic,
>
> Many practicioners does not have knowledge enough to be pragmatic and
> they are forced to be dogmatic.

Yes, it is a shame that those fresh out of higher ed do seem dogmatic about both relational databases as being the best databases and OO as the best programming languages, based not on practice, but the sermons they have heard in the classroom and read in their text books. The advocates in both of these areas have a pitch that resonates with professors and/or text book writers & publishers. I think both OO and relational theory ought to be taught side by side with alternatives and pros & cons of each. There is not one correct mathematical model for data, metadata, nor functions (by whatever names).

> >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 -- and that is what's "evident" to "the vast majority of the OO
> >coders", I suspect.
>
> What is evident is that the equation: type = variable does not work.

I agree.

> >> 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 class is a type and a class definition is a type definition.
>
> Many people confuse a class with its definition.

Me, for exampe. The term is used both ways. I prefer to think of a class as a specification for (that is, metadata regarding) a domain/type. What we can "see" of the class is a specification "in writing" (e.g. MyType.java) and a compiled version of that spec (e.g. MyType.class). The set of objects that could be instantiated by way of this specification of the type is more abstract. So, I prefer using the term "class" as a definition/spec of a type and the term "type" as the more abstract (invisible) set. I think this helps avoid some of the confusion in terms, perhaps, maybe, a little bit.

> > A type, being a domain, is a
> >set. 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).
>
> A class being a type is a set (among other things).

See how confusing that terminology is?

> >> 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..
>
> No, code does not have any relationship with metadata.

really? What about the declarative code that specifies constraints on the data -- is that metadata? If the same information is in a procedural language, does it cease to be metadata at that point?

> The metadata of
> a type is the name of the type, the number of the possible
> representations and their names, the name of the representation's
> components, their types, etc.
>

maybe that's the meta-metadata?

--dawn Received on Wed Apr 14 2004 - 18:27:23 CEST