Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Clean Object Class Design -- Circle/Ellipse

Re: Clean Object Class Design -- Circle/Ellipse

From: Bob Badour <bbadour_at_golden.net>
Date: Sun, 2 Sep 2001 00:37:24 -0400
Message-ID: <WHik7.649$UY2.127714353@radon.golden.net>

Dmitry A. Kazakov wrote in message <3b913737.1293936_at_news.cis.dfn.de>...
>On Fri, 31 Aug 2001 22:11:11 -0400, "Bob Badour" <bbadour_at_golden.net>
>wrote:
>
>>>>You've lost me here. What exactly am I mixing? A value is a value.
>>>
>>>Yes, and any value has a type.
>>
>>Any value has multiple types: its most-specific type and all of its
>>inherited types.
>
>We disagree here. Any value has exactly one type.

If we accept your assumption that no such thing as subtype exists, we can end this conversation now. The conversation is, after all, a discussion of subtype.

>>>>>Unfortunately most of OO languages do not differentiate them.
>>>>
>>>>Most OO languages do have the notion of a most-specific type, a declared
>>>>type and a general (polymorphic) type.
>>>
>>>Yes, but they do not differentiate specific and class-wide types.
>>
>>You are again confusing things by introducing undefined, unecessary new
>>terminology. "class-wide type" is meaningless.
>
>It is by no means meaningless nor new. For a definition see Ada
>Reference Manual.

I have no interest in reading the ADA reference manual. This thread is in comp.object not in comp.lang.ada -- it's not even cross-posted there.

>The term "class" is used for a set of types derived
>from a given one.

This is not the accepted use of the term "class" in OO. The ISO standard vocabulary for programming languages equates "class" with data type.

>The type representing that set is called class wide.

Since "class" equates with "type", class-wide type is meaningless.

>The values of that type are class wide values.

Again, this is meaningless.

>>"Most-specific type", 'declared type" and "inherited type" have meaning.
>
>How many types has the value 1, provided that I can derive from
>integer?

Integer is rational is real is complex.

Natural is whole is integer.

Any others you would like to propose?

>>>>>A specific Circle is not an instance of Ellipse. It is an instance of
>>>>>Circle.
>>>>
>>>>An instance is not a value -- it is a variable.
>>>
>>>No. An instance of a type is a value of that type.
>>
>>Values do not change -- ever. Do instances? Instances are variables.
>
>Instance of a type is a value

Incorrect. Instance of a type is a variable of the type.

>Instance of a generic function is a function

Functions change.

>Instance of a generic type is a type

A parameterized variable of a generic type.

>Instance of a task type is a task

Tasks change.

>>Consider: Values exist regardless of whether any representation currently
>>exists for them in the universe. The value 5 exists even if it appears
>>nowhere in your application or your computer at some point in time.
>
>It is a pure phylosophical argument, however if you interested to know
>I do not support Plato's theory. So it does not work for me. 5 is just
>a set of shining dots appearing to be on my screen which by the way
>does not exist together with that dots because I am an inveterate
>solipsist. (:-))

In that case, this discussion is pointless.

>>>A variable of some
>>>given type may hold values (instances) of that type.
>>
>>This is a common misconception. A reference to a variable of some given
type
>>refers to a specific variable (instance) of that type.
>
>In short, reference to a variable refers to a specific variable.
>That's true.
>
>>An instance (variable) of some given type may hold values of that type.
>
>>Variables have identity. Instances have identity. Values are identity.
>>(Values are self-identifying, if you prefer.)
>
>Yes, values are states. Variables have states = values.
>
>>One can have pointers to an instance. One can have pointers to a variable.
>>One cannot have pointers to a value because self-identifying values exist
>>independent of representation. (One can point to a representation of 5,
but
>>one cannot point to 5.)
>
>I'd put it so, values do not exist without variables [in a language].

The value 10^(10^(10^(10^(10^(10^(10)))))) existed even before I represented it and even though I have no numeric variable in which to store its value.

>To have a value (point it, pass it etc) one should have a variable
>that holds it.

One could have a literal or a constant.

>You are trying to say that behind every value there is
>an ideal, abstract value existing outside the language, the soul of a
>value, so to say. OK, let it be so. It is irrelevant.

It is relevant to the user of the DBMS.

>>>>I agree that Circle
>>>>variables are not Ellipse variables and vice-versa. The same is true of
>>any
>>>>subtype variable and supertype variable, which is why I think
well-thought
>>>>languages must clearly distinguish between variable and value.
>>>
>>>They are well distinguished in any language.
>>
>>If that is so, why does C++ have any difficulty implementing the very
>>natural subtype/supertype relationship between circle and ellipse?
>
>Because LSP [+definition of property] is formulated so, that it is
>impossible.

Sorry, but you are putting the cart before the horse. If we apply LSP to values of ellipses and values of circles, we see that it is not only possible but entirely desirable.

>There are fundamental reasons behind this.

Only because the language makes insufficient distinction between value and variable.

>C++ is bad, but
>for LSP there is no cure. This is why I am against LSP.

If one applies LSP separately to variables and values, it is cured.

>>>More important is that
>>>one should distinguish between readonly (in) and full access (inout,
>>>out) variables.
>>
>>I disagree. Constraints on variables are nowhere near as fundamentally
>>important as a distinction between the very different concepts of value
and
>>variable.
>
>You pointed the distinction: values are immaterial and enjoy
>witnessing of the God of programming. Variables are sinful and
>condemned forever. (:-)) Seriously why in your opinion, say in C++,
>values and variables are not distinguished?

Update operations necessarily operate only on variables while non-update operations necessarily operate only on values, and C++ makes no distinction between the two. Constraining a variable to a single value or a subset of values is a different matter.

>>>>>In contrary to this both a class-wide Circle and a class-wide
>>>>>Ellipse are instances of Ellipse'Class [not Ellipse!]. A class-wide
>>>>>value consists of the type tag indicating the type and the value of
>>>>>that type [In C++ the type tag is allways in the value, which leads to
>>>>>confusion].
>>>>
>>>>Values have no type tags -- they just are. All of the above are simply
>>>>implementation issues and are ultimately irrelevant to the discussion at
>>>>hand -- as is the rest of your example.
>>>
>>>Disagree. Values of class-wide types always have a tag associated with
>>>them.
>>
>>Again, you are confusing things by introducing undefined, unecessary new
>>terminology. "class-wide type" is meaningless.
>>
>>The "tag" to which you refer is an implementation detail. Obviously, the
>>DBMS must know both the type and the representation of that type in use at
>>any given moment. Whether the DBMS implements this with a tag is
irrelevant
>>to the discussion of type inheritance.
>
>This is the key issue for inheritance and dispatch. To know the
>representation one should know the type. The type can be known either
>statically or at run time. In the later case there should be a tag to
>indicate the type.

This exchange is pointless. I have no interest in discussing implementation details when discussing the topic of subtype and supertype. The implementation details are irrelevant to the topic.

>>>An representation issue is whether the
>>>tag is embedded in the value or not.
>>
>>Physical independence requires that the representation be unimportant to
the
>>user, which makes it irrelevant to the discussion at hand.
>
>It is very important to the user whether a value is tagged or not.

Believe me: The user could not care less how the DBMS implements polymorphism as long as it works. Assuming a tag eliminates any other possible solution, which reduces flexibility at the physical level. Exposing the implementation to the user does even worse damage.

Representation is irrelevant to the discussion at hand.

>>>>Your example did nothing to address the statement that a circle value,
no
>>>>matter the representation, is an ellipse. It has all the properties of
an
>>>>ellipse.
>>>
>>>My point is that a circle value is not an ellipse. It mimics an
>>>ellipse, because there is a defined conversion to ellipse.
>>
>>Your statement that a circle value is not an ellipse does not change the
>>fact that it is. Conversion is unecessary.
>
>Here is a proof:

Bullshit. That was no proof.

>>>-1 is not
>>>double
>>
>>I disagree. In a poorly designed language, it might not be. But -1 is a
>>valid value for a double precision floating point number. -1 is a valid
>>rational and real.
>
>-1 is a literal of integer type. Or are you arguing that -1 belongs to
>the set of real numbers? That is also true. But those -1s are
>different ones.

In my language, -1 is a literal of real type also.

>>>yet fabs (-1) is legal.
>>
>>I thought we were discussion object oriented languages.
>>
>>Should we not discuss whether Abs(x) is legal or whether Magnitude(x) is
>>legal instead? Why should we introduce type-specific names for the
operation
>>when we can assume polymorphism?
>
>fabs is not polymorphic [unfortunately it is impossible in C++].

fabs is not object oriented -- it exists in C, which says nothing about C++ and nothing about the topic of discussion.

>>>How
>>>the compiler would distinguish them?
>>
>>The DBMS knows and understands its internals. How would it not?
>
>Here is a contradiction. You say that representation is not an issue

It is not an issue to the user because the principle of physical independence prohibits the DBMS from exposing any detail of the representation to the user.

>and immediately propose to distinguish types by their represenation.

I have stated exactly the opposite -- you are the one who proposed different representation-based types. Please do not put words in my mouth. I am quite capable of doing that myself.

>>>If they are distinguishable, then
>>>why not to call them [sub]types?
>>
>>If they are indistinguishable to the user, why not call them the same
type?
>
>They are same. Consider it as an axiom: "If two types are
>undistinguishable they are same. If two types are not same then either
>one is a subtype of another or they are unrelated."

I can accept that provided we accept that representation is orthogonal to type.

>>>Different types?
>>
>>Nope. Different representations of the same type.
>
>Remember, you said that representation determines the type.

Hell no! Two floating point numbers do not a complex make!

>Either the
>type determines the representation [my point]

Type constrains the possible representations but does not necessarily determine representation.

>then several types may
>have same representation

True. Many types might use two real numbers for their physical representation.

>[=abstraction]

Sorry. I have been discussing physical representation vs. type. The abstraction is the type itself.

, or [your point] the
>representation determines the type, which is IMO hard to defend.

Not my point. My point is: Type does not determine representation and representation does not determine type.

>>For instance, the DBMS
>>might allow both cartesian and polar representations of complex numbers.
The
>>user should not have to care which representation any given variable
stores
>>at any given time. The operations and values are equivalent regardless of
>>the representation used.
>
>It is easy to achive. Derive polar complex from cartesian one and make
>it both a sub- and supertype. Here you are.

Your example does not achieve the desired result. Complex is a single type regardless of the physical representation.

>>>So you naturally
>>>come a cristal clear idea: a value has a type.
>>
>>Yes. Ane one naturally comes to the crystal clear idea that a type has
>>multiple equivalent representations.
>
>In which sense equivalent?

The imaginary unit has two equivalent representations: cartesian and polar. The representation does not change the value nor the value's type.

>How do I distinguish that representations?

If the user wants to know the polar representation, the user queries the magnitude and phase (or angle) attributes of the complex number. If the user wants to know the cartesian representation, the user queries the real-part and imaginary-part attributes of the complext number.

At no time should the DBMS reveal to the user which representation a given complex variable contains.

>And how do you call the set of all values having exactly one [of that
>multiple] representation. I would call it a type. And you?

I call it the empty set. All of the values have both representations.

>>>A type has an implementation.
>>
>>I disagree. It has multiple implementations. There are more than one way
to
>>skin a cat, after all.
>
>Again, there should be a construct behind an implementation [among
>many].

Physical independence requires the DBMS to allow as many implementations as are required.

>It seems that you have no name for that.

I call it physical representation or storage.

>My proposal to you is
>to consider the following naming convention (used in Ada). What you
>call "type" [with multiple representations] is a class-wide type. What
>you have no name for, is a normal type.

My proposal to you is to consider the generally accepted naming conventions. What you call a "class-wide type" is the set of specific types that a variable of a declared type can contain -- either directly or through inheritance.

What you claim I have no name for is an abstract data type. (See ISO/IEC 2382-15.04.02)

>>>It is actually what subtyping is for. Isn't it?
>>
>>No. Subtyping is for subtypes not equivalent representations of the same
>>type.
>
>Equivalent in what sense. You claimed that representation is not an
>issue for types [I completely agree with that], hence for subtypes
>too. Whether a type is a subtype shall be representation-independed.

A complex number with cartesian representation (0,1) is eqivalent to and equal to a complex number with polar coordinates (1,Degrees(90)).

>>>class Circle : public RosaElephant, public Ellipse {...}
>>>
>>>You cannot pass such circle to an ellipse method without conversion.
>>
>>In the specific implementation of your compiler, perhaps, but that says
>>nothing about subtypes and supertypes in general.
>
>In which compiler it could be possible?

In any compiler that fully supports polymorphism.

>>>>It could be done without any conversion at all. In fact, physical
>>>>independence almost requires it.
>>>
>>>This
>>>
>>>1. Exposes representation, because it requires that a subtype have
>>>same representation as the base.
>>
>>No, it does not. It requires that the DBMS understand how to operate on
>>different representations of the same type without conversion, and it
>>requires that the DBMS understand how to operate on subtypes without
>>conversion.
>
>Let it understand, but how it could operate?

Using operations. What makes you think it could not?

>>>2. Eliminates multiple inheritance.
>>
>>Again, it does not. You are confusing unecessary implementation details
with
>>essential aspects of the problem.
>
>Representation is indeed an implementation detail, so I do not want
>the representation of a subtype be limited.

Good. You agree with the principle of physical independence. Received on Sat Sep 01 2001 - 23:37:24 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US