Re: Microsoft and the two great blunders

Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<bsnjnj$er8qp$1_at_ID-152540.news.uni-berlin.de>...

> > No, relation is the short for relation value and relvar is the short
> > for relation variable.
> >
>
> Well, we were talking about table and table is a shortcut for relvar.

Only one letter shorter, but which is the vulgar term for relation value?

> > The number of values of the Employee type is virtually infinite!
> >
>
> Yes, but the one that do apply is typically finite.

The combinations of all possible past present and future names, addresses, phones, wages, etc, etc.

> Plus what's the
> problem in opearting over infinite value ?

No problem, but we have to clearly distinguish between the infinite set of possible valid employee values and the value of the employees table variable in a concrete moment of time. That's all.

> > You are mixing apples with oranges. The proper question should be: Are
> > operators definitions part of type definition?
>
> There's two concepts typically: the definition and the declaration. If
> any, operator declaration should be part of type declaration, to
> preserve some very important principle of mathematica notation :
>
> *locality of reasoning*

And what's the problem?

D&D proposal is neutral about that. You can declare operators where and when you want.

> There are also other principles and concerns like modularity and
> compositionality that are as clear as mud with D&D proposal.

Are they incompatible?

> > But one operator may be shared by several types.
> >
>
> Where shared means ??

Two types have a set of operators each one. Those sets may overlap.

For instance imagine a type "Time" and a type "Acceleration". The commutative dyadic infix operator called '*' with operands of type Time and Acceleration is part of both types operators set.

> >>>>TYPE ELLIPSE
> >>>> IS PLANE_FIGURE
> >>>> POSSREP { A LENGTH, B LENGTH, CTR POINT };
> >>>
> >>>
> >>>It is not a complete type definition.
> >>>
> >>
> >>So what would be the complete type definition ?
> >
> >
> > The operators definitions are missing.
> >
> >
> >>Oh. But
> >>
> >>type Plane_Figure union;
> >>
> >>Is void of content.
> >
> >
> > Because we have not added the operators definitions.
> >
> >
>
> And the way to add that is ... ?

operator Area(P PlaneFigure) returns Area; operator Center(P PlaneFigure) returns Point; ...

> >>A proper abstract data type is something entirely
> >>different
> >
> >
> > I meant it is similar to an "abstract class".
> >
>
> Except it isn't similar to an abstract class.

Why not?

> > A union type. A supertype for all plane figure types. It does not have
> > a representation, but it may have operators. It may resemble to a Java
> > "interface".
> >
>
> A union type and a supertype are very different things.

Not in D&D model.

> Nobody said that types were variables.

But many people say and write that the cool thing is to map types to variables.

> But the very fundamental things
> you want to talk about, you don't grasp.

The very fundamental issue does not have relationship with type theory. The old SQL-89 type system is enough for most business systems.

It is evident that tables are not classes and can not map to clases, so people say that they map classes to tables but they are really mapping tables to network structures, exposing pointer to users, and managing data navegating through the networks using procedural code. This is the essence of both great blunders.

With a persistence layer you don't manage data represented by relations using relational operators. You manage data transversing pointer labyrinths using low level procedural code.

The problems of this approach are more than evident to me.

> >>So what ? People are free to waste their time however they wish.
> >
> > So many people hardly can be more confused and misleaded. But of
> > course they are very free to waste their time and the resources of
> > their employers.
> >
>
> And you'd like people to waste resources on Tutorial D, instead ?

That is not the question. The question is that such frameworks are a monstrousity. They are a lot worse than the old client server SQL systems. As I said before it is a movement from bad to worse.

> That would not be an unreasonable wish, except that people are free to
> waste their time on whatever they see fit. And if you want to shame them
> into wasting time on what you think fit, well, you have no proper argument.

If they are free to waste time trying to return to the prehistory then I am also free to rant all I want :)

> Indeed, it is hilarious that you are ignorant and proud of it.
>
> Again, for your own good you might be well advised to buy Thalheim's
> book. It may as well give you some insights into the relation between
> database theory and type theory.

I would not buy a book with such title. I don't have any interest on the E/R model, it is unnecessary, insufficient and unuseful.

> Ha, ha, ha. It turns out that the self-appointed educator needs to
> edcuate himself first.

I was not trying to educate anybody, I only posted a hard to find link about the next nonsense.

Regards
  Alfredo Received on Mon Dec 29 2003 - 18:07:37 CET