Re: Fraud Number 3: U-Gene

Tony D wrote:
> Cimode wrote:
> > First, I am aware of Date's definition and I do not quite feel
> > confortable with it because it focuses too much on structural
> > definition and not enough on the characteristics values extraction from
> > domains. Neverthless, Date's is logically correct: it's a matter of
> > perspective.
> >
>
> Well that's reassuring; although you're right on the potential for
> overemphasising structure.
>
> > I also believe some of Date's definition can also lead to
> > confusion..For instance, Date's definition relvar could lead to
> > confusion with the definition of an attribute. (both have a name, a
> > data type and may hold a value in time). If we define, attribute and
> > relvar alike, one take the risk of confusing them...
> >
>
> But I'm not sure how you could confuse an attribute with a relvar.
As I stated B4 if their definition are too similar to be clearly distinguished..It's an open highway for unexperienced audiences to confuse both. This is the last explanation I will give on that point...I have already answered above and I will stop reexplaining....

> A
> relvar is a variable and can indicate different values at different
> times. A relation value is value; like an integer value, it never
> changes. You can change which relation value a relvar indicates, but
> you can't change the relation value itself. So, you can't "change" an
> attribute.

*change* is a verb that leads to confusion in defining the relationship between variables and values. *change* supposes a modification of state which. I prefer the definition of variable as a *value holder* which give a much more clearer indication .

> [ snippage ]
>
> > For instance, Pascal defines a data type as the combination of:
> >
> > --> a name
> > --> set of constraints regulating *extraction* of values from a
> > specific domain
> > --> set of operators applyable in specifc context
>
> Which marks a difference between domains and types that I don't
> currently hold; the definition of a type as a set of acceptable values
> (or equations defining a set of acceptable values) plus a set of
> operators over those values seems simpler and no less expressive.
You are confusing domain and type...
A domain is what hold the *possible* values... A data type is defined (thanks to type constraints and operators) to express *permissible* values extracted from a domain...You could perceive a type as a subset of domain defining all specific operations to the syste + inheriting all characteristics of the domain superset + defining all constraints defining the rules by which the values are made *permissible* AFTER domain extraction... Received on Tue Jun 20 2006 - 12:49:59 CEST