Re: Date's First Great Blunder
Date: Thu, 15 Apr 2004 12:28:08 GMT
Message-ID: <407e7725.5656954_at_news.wanadoo.es>
On Wed, 14 Apr 2004 11:27:23 -0500, "Dawn M. Wolthuis"
<dwolt_at_tincat-group.com> wrote:
>Not to me, it isn't. Mathematical models are simply models/metaphores.
They are formal representations.
> 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.
It should not have relationship with beliefs. It is proven that it is
simpler than the known alternatives.
>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.
Most if not all of the advocates of the network and hierarchical
approaches never tried The Relational Model, thus their experience has
little value. It is hard to practice with something never implemented.
>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.
I agree, although they are independent. Relational theory is for data
management and OO is for coding.
>one correct mathematical model for data, metadata, nor functions (by
>whatever names).
But there is one best approach for data management.
>> What is evident is that the equation: type = variable does not work.
>
>I agree.
Then it is obvious that you disagree with class = 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.
Indeed, it is the typical fuzzyness of OO. OO terms have many meanings and communication and precise thinking is very difficult.
> I prefer to think of a class
>as a specification for (that is, metadata regarding) a domain/type.
It does not change the things a lot. The equation: type specification = relvar is as blunderous as type = relvar.
>> A class being a type is a set (among other things).
>
>See how confusing that terminology is?
Yes, that's why I tend to avoid the "class" term and to use "type", "type definition" and "type implementation" instead.
Bad terminology leads to bad thinking.
>> No, code does not have any relationship with metadata.
>
>really? What about the declarative code that specifies constraints on the
>data -- is that metadata?
Regards
Alfredo
Received on Thu Apr 15 2004 - 14:28:08 CEST