Re: Clean Object Class Design -- Circle/Ellipse
Date: Sun, 30 Sep 2001 15:30:52 GMT
Message-ID: <3BB73A9B.6020306_at_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.
>
>
- You are using the term 'variable' differently than everyone else. This is at least going to cause confusion.
- 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 - 17:30:52 CEST