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: James A. Robertson <jarober_at_mail.com>
Date: Sun, 30 Sep 2001 15:30:52 GMT
Message-ID: <3BB73A9B.6020306@mail.com>


Bob Badour wrote:

> "James A. Robertson" <jarober_at_mail.com> wrote in message

> In Smalltalk, all named variables contain references to dynamically
> allocated variables. An instance of Object is a dynamically allocated
> variable in memory. As an aside, the type of all named variables in
> Smalltalk is reference to a reference to a value representation. The type of
> the value contained in all named Smalltalk variables is a reference to a
> value representation, which is of course different from the type of the
> named variable.
>
>

  1. You are using the term 'variable' differently than everyone else. This is at least going to cause confusion.
  2. Why does it matter in any way?

>

>>do you see any variables in the expression above that creates an instance?
>>

>
> Yes, I do. The instance itself is a variable dynamically allocated in
> memory.
>
>
>
>>>According to the definition of the Smalltalk language an instance is a
>>>variable that one can reference. One cannot reference a value. Values
>>>

> are
>
>>>self-identifying.
>>>
>>>
>>>
>>
>>Sigh.  You are being extremely pedantic.  Explain how your definitions
>>relate to anything useful.  Then, find me an actual use of them that
>>relates to Smalltalk.
>>

>
> They relate to the topic under discussion: type inheritance. Because a
> variable is a different type than a value, Circle value is a subtype of
> Ellipse value while, at the same time, Circle variable is not a subtype of
> Ellipse variable. When people argue that Circle is not a subtype of Ellipse,
> they invariably apply LSP beyond its proper scope by assuming that values
> and variables are the same type.
>
> The statements above apply equally to all subtype/supertype relationships
> between a subtype value, SUBV, and a supertype value, SUPERV. A SUBV value
> is a subtype of SUPERV value while, at the same time, SUBV variable is not a
> subtype of SUPERV variable.
>
> When someone argues that SetFoci or SetMajorAxis operations violate LSP,
> they ignore the fact that such update operations necessarily operate only on
> variables. ie. They do not apply to values, which cannot change.
>
> In any language that makes proper distinction between variables and values,
> the alleged problems with type Circle inheriting type Ellipse disappear. The
> OO pundits that argue against such an inheritance merely demonstrate that
> their favourite language makes insufficient distinction between value and
> variable -- Smalltalk included.
>
> As it happens in another sub-thread, a Smalltalk bigot called C++ crappy,
> and I observed that all current OO languages are about as crappy as C++. I
> asked "Why not Smalltalk?" Smalltalk pundits incorrectly argue that Circle
> is not a subtype of Ellipse. Smalltalk makes insufficient distinction
> between values and variables. Given that the product manager for a smalltalk
> implementation has the confused idea that instances are (or can be) values
> proves the point.
>
> Variables can contain the representation of some value, but variables are
> not values. Variables change; values do not.
>
> If one applies the SetMajorAxis operation to an ellipse variable that
> happens to contain a circle value, the language should allow the operation
> regardless. After the operation, the variable still contains an ellipse
> value, which is a valid value for the ellipse variable, even if it is no
> longer a circle value.
>
> Mr. MacDonald, the troll who hijacked the thread with the absurd claim that
> "Smalltalk *has* instances that are values", has already admitted that his
> motives were to attack without attempting to learn or to communicate. I do
> not know why you would want to take up his cause.
>
>

So the premise of all those words is that I can't subclass Circle from Ellipse in Smalltalk and properly replace it?

First, if I create a subclass, I override any methods no longer work properly. There is no problem here for a <competent> software developer. Basically, you are arguing a dry academic point that has no relevance to software development.

I think I know who the troll is; it's not MacDonald...

>>I find little merit in your definitions.  They don't relate to solving
>>any real problems in development; they don't relate to any useful
>>information at all.
>>

>
> Au contraire, subtype/supertype relationships arise in many, if not most,
> real problems in development. Any language that prohibits the user from
> modelling natural subtype/supertype relationships such as Circle/Ellipse
> interferes with development. For any such language, all inheritance will be
> arbitrary, ad hoc and unrelated to either the problem domain or the solution
> domain. No developer will ever have objective guidelines for when to use
> inheritance vs. roles, delegation etc.
>

Funny how this never seems to come up as an issue in system development then. When subclassing, one overrides methods as needed.

Heck, subclassing should be used sparingly anyway.

> I find it very telling that almost every OO pundit has found it necessary to
> write an apologia explaining why the very real and natural subtype/supertype
> relationship between circle and ellipse does not apply in OO.
>

I find it telling that you worry about this at all. Go do some system development and see how often this problem actually arises.

>
>
>
Received on Sun Sep 30 2001 - 10:30:52 CDT

Original text of this message

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