Re: Clean Object Class Design -- Circle/Ellipse

Richard MacDonald wrote in message
<_ssk7.4288$Uf1.313936_at_bgtnsc06-news.ops.worldnet.att.net>...
>"Bob Badour" <bbadour_at_golden.net> wrote in message
>news:Pthk7.641$m%1.127427644_at_radon.golden.net...
>> James A. Robertson wrote in message <3B906770.E1C0185E_at_mail.com>...
>> >Bob Badour wrote:
>> >>
>> >> James A. Robertson wrote in message <3B8A6798.A8F25218_at_mail.com>...
>> >
>> >> >> >1) Smalltalk is a crappy language
>> >> >>
>> >> >> Actually, I said it is just as crappy as C++, which does not say it
>is
>> >> >> crappy.
>> >> >>
>> >> >
>> >> >Can you list your specific complaints?
>> >>
>> >> We can start by observing that Smalltalk, like C++, makes insufficient
>> >> distinction between values and variables.
>> >>
>> >
>> >hmm - C++ variables and Smalltalk variables are entirely different,
>> >leading me to wonder how well you know Smalltalk.
>>
>> I know that variables change while values do not. If Smalltalk gets
>> something this fundamental entirely wrong, then it is much worse than
C++.
>
>Your wiggleword was "if". Glad you used it because it means you have a
>correct sentence. A completely useless sentence, but still correct.

And another completely useless response from you.

>> >In C++, one declares
>> >a variable as a type, thus determining the specific storage type to be
>> >used by that variable.
>>
>> This is one way to make insufficient distinction between value and
>variable.
>>
>>
>> >In Smalltalk, variables are not declared as
>> >being of a specific type - they are references to arbitrary objects.
>>
>> And the "arbitrary objects" are themselves variables. ie. They might
>change.
>
>Or might not. A variable can hold onto 5. 5 does not change.

A variable can change. That does not say it must change. A value cannot change. A variable that does not change for a specified period of time is still different from a value which can never change.

Ultimately, a variable and a value have different types. A variable is a reference to a value -- or more precisely to the representation of a value.

>> >> Perhaps, Richard would like to list his specific complaints that are
>> >> pertinent to the discussion at hand? Or would you like to offer one or
>> more?
>
>Specifically, you're making an error that may or may not be important.

I am not the one making the error.

>Smalltalk has Objects that are values.

Sloppy terminology -- nothing more. Smalltalk has object variables as well as object values. So?

>You've been asked what you would call the thing/type/whatever that
>is both variable and value.

No such thing exists. Variables can change while values cannot.

>I don't think you answered.

I wasn't aware that anyone asked. Considering that the answer is so simple and that I know I have repeated the base observation many times now, I am surprized you even required an answer.

>I assume its
>a concept that is foreign to you and hence irrelevant.

It is an impossible concept. Variables can change while values cannot. Even a variable constrained to a single value is different from a value.

>Well, for an
>OOist, that thing is Object.

Define "object". You are simply falling into the prevalent habit of sloppy ill-defined terminology. That's fine if all you want to do is obfuscate your own confusion, but it doesn't help much with actual communication.

Object values are different from object variables. Object values are different from object constants. Object values are different from object literals.

>You may have something useful to say,
>but since we part company at such a fundamental level, its hard to know.

You would have to overcome your confusion to know.

>> >> >> >2) Instances are not values.
>> >> >> >
>> >> >> >Since Smalltalk *has* instances that are values (the number
>> >> >> >5 comes mind),
>> >> >>
>> >
>> >Generally (In VisualWorks, most others are roughly similar), a variable
>> >references an object.
>>
>> A named variable references an object variable.
>>
>>
>> >In fact, it refs an object header, which in turn
>> >refs the actual object.
>>
>> In fact, it refers to an object header variable, which in turn refers to
>the
>> actual object variable.
>>
>>
>> >There are exceptions; one can have 'immediate'
>> >objects, where the header actually holds the object (SmallInteger
>> >objects, for instance).
>>
>> There are exceptions; one can have 'immediate' object variables, where
the
>> header variable actually holds both the header variable and the object
>> variable.
>>
>>
>> >For the developer, this doesn't actually matter.
>>
>> Except that Smalltalk makes insufficient distinction between value and
>> variable preventing the developer from establishing proper, natural
>subtype
>> relationships.
>
>How do you know this?

I have seen the Smalltalk proponents argue against modelling Circle as a subtype of Ellipse.

I have seen your own confusion over the difference. If you program in Smalltalk and Smalltalk made sufficient distinction, you would have clearly understood the difference prior to entering into this exchange.

>> >In fact, if you think
>> >it matters, then you are paying way too much attention to detail.
>>
>> None of the irrelevant details you mentioned in your post matter. It only
>> matters that Smalltalk makes insufficient distinction between values and
>> variables, which I think you have amply demonstrated.
>
>When people talk at cross-purposes, they generally come out of the
>discussion with the same pre-ordained opinions they went in with.
>As an observer, I don't see how your conclusion has been demonstrated.

As a participant, you have demonstrated my conclusion very well. Received on Tue Sep 04 2001 - 09:29:07 CEST