Re: Clean Object Class Design -- Circle/Ellipse
Date: Thu, 18 Oct 2001 14:05:53 GMT
Message-ID: <3BCEE2A2.200_at_mail.com>
Bob Badour wrote:
> "James A. Robertson" <jarober_at_mail.com> wrote in message news:<3BC59460.3090400_at_mail.com>...
<snip>
>>>>>* allow me to send the setFoci message to ellipse variables (that >>>>>incidentally contain circle values) with two different focal points? >>>>> >>>>I override the methods in the subclass so that each gets appropriate >>>>behavior. If the ellipse variable contain circle values, ,my >>>>application code is wrong> >>>> >>>Are you saying that Smalltalk does not allow polymorphism? >>> >>How does that follow from anything I said? >>
>
> If Circle is a subtype of Ellipse, Ellipse variables can contain
> Circle values.
>
No, not really. When I send my instance creation message to an object, I set said values. I set them in an appropriate fashion for my object. If I get values that are imappropriate, it's an application error that has <nothing> to do with the implementation issues of object storage. I am as likely to make such an error in any arbitrary language, since it's dependent on my understanding of the object model.
>
>
>>I could just as easily have >>declared Ellipse to be subclassed from Object and supported the same >>protocol. >>
>
> What does the supertype of Ellipse have to do with whether Ellipse
> variables can contain subtype values?
>
Nothing. And your points are confused. Are you trying to be dense? Sketch out for me <in code> how your problem crops up.
>
>
>>>>>* prevent me from sending the setFoci message to circle variables? >>>>> >>>>> >>>>See above. >>>> >>>Overriding setFoci does not prevent me from sending the message, does >>>it? >>> >>No, but I can override it in such a way as to make it irrelevant - >>raising an exception, for instance. >>
>
> In a weakly typed language like Smalltalk, I suppose that is as much
> as we can hope for. However, I see little utility in weakly typed
> languages -- especially for database management.
>
>
Smalltalk is strongly, but dynamically typed - an object will not execute a message it does not understand, and will respond to such messages in a clearly defined manner. Unlike (say) C or C++ which are weakly and statically typed - using casts or void pointers, I can get objects to attempt to execute anything - and get completely undefined behavior.
It's fairly clear at this point that your understanding of Smalltalk is slim. Have you merely read documents, or have you actually used the language?
>
>>If the developer using the new >>class doesn't know how to use it, that's not really my problem, is it? >>
>
> If you are modelling types for a database, it is.
>
>
No, it's not. You'll get this kind of problem in any language with untrained developers. If you think otherwise, you are quite simply naive beyond belief.
>
>>>>If I find that I'm overriding enough methods, subclassing was a bad >>>>choice. You have created an example 'problem' that isn't much of a >>>>problem. >>>> >>>> >>>If Smalltalk made sufficient distinction between values and variables, >>>one would not need to override setFoci in the Circle class because it >>>would never inherit the method. Circle values would inherit the >>>operations on Ellipse values but Circle variables would not inherit >>>the operations on Ellipse variables. >>> >>If you understood Smalltalk, you wouldn't make such egregious errors in >>your postings either. Have you ever used Smalltalk? From what vast >>well of experience do you draw your silly statements from? >>
>
> What egregious error? While several people have made this bold claim,
> nobody has yet demonstrated a single one.
>
See my last post. Received on Thu Oct 18 2001 - 16:05:53 CEST