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: Richard MacDonald <macdonaldrj_at_att.net>
Date: Wed, 05 Sep 2001 04:40:55 GMT
Message-ID: <r1il7.7908$Uf1.623246@bgtnsc06-news.ops.worldnet.att.net>


"Bob Badour" <bbadour_at_golden.net> wrote in message news:To%k7.788$h37.136172664_at_radon.golden.net...
>
> 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.

Correction: Completely useless but *correct* response.

>
> >> >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.

All this is basic and known to all of us.

The Smalltalk object representing 5 is a value. This is where you went wrong. Perhaps if you backed up and dealt with that.

> 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.

We hear you.

> >> >> 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.

See above.

> >Smalltalk has Objects that are values.
>
> Sloppy terminology -- nothing more. Smalltalk has object variables as well
> as object values. So?

Well I don't know. You're supposed to be the expert. I was just correcting your mistake. I'm sure I'm not qualified to know if that's important or not. But as God said: All minor imprecisions are major.

> >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.

My mistake. I meant to say: *either* variable or value. You know, an Object.

>
> >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.

Well I didn't typo it the first time, but that's all water under the bridge.

>
> >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.

Well, sorry for my typo here. I have an Object, and subclasses can be of type Variable or Value. I know us OOists don't have your marvelous theory to match, but at least we have a real behavioral engine. I was just wondering if your vast expertise could help us figure out how we should refer to Object.

> 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.

Consider it a slip of the keyboard. I'm sorry I wasted your time sending you down the wrong path. My mistake.

>
> >> >> >> >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.

Actually, as one who does mathematical work with shapes, I like to use the value viewpoint, which puts me in your camp. My Circle and Ellipse would be very similar to yours. But I've seen that my model is impractical in the graphical manipulation world (try dragging a value). So given the choice between "correct and irrelevant" or "pragmatic and useful", I sympathize with the latter.

> 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.

Oh I think I do understand it. And I agree with Date that it is important.

> >> >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.

No, I just typed "both" when I should have typed "either". Correctable. You still haven't corrected for your error. You're just bashing OO languages. Received on Tue Sep 04 2001 - 23:40:55 CDT

Original text of this message

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