Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news4.ner.bbnplanet.net!news3.near.net!paperboy.wellfleet.com!news-feed-1.peachnet.edu!gatech!news.sprintlink.net!mv!usenet
From: rapp@lmr.mv.com (L. M. Rappaport)
Subject: Re: Smalltalk terminology - Object, Class, and Instance
Message-ID: <DAy8HC.417@mv.mv.com>
Nntp-Posting-Host: lmr.mv.com
Sender: usenet@mv.mv.com (System Administrator)
Organization: MV Communications, Inc.
Date: Thu, 29 Jun 1995 22:22:42 GMT
References: <3shvfp$l9k@portal.gmu.edu> <DAsuBL.9Ir@mv.mv.com> <3sp5eg$kos@access5.digex.net> <DAwJ46.94J@mv.mv.com> <3sss3b$27r@access5.digex.net>
X-Newsreader: Forte Free Agent 1.0.81
Lines: 79

bpetros@access5.digex.net (Barry Petros) wrote:

...edited

>Everything is an object.  Objects *only* respond to messages.  (or as I
>prefer it, The only way get something to happen in smalltalk is to
>send a message to an object). 

That's good.

 
>Now what happens? The beginner needs some *experience*.  He needs to sit
>down and write a method in smalltalk.  What two things does a smalltalk
>programmer need to know before writting a method?  What class the method
>belongs to and if it is an instance method or class method.  This instance
>method and class method thing really throws new programmers.  (Actually
>I believe that is the fact that procedure/method lookup is done by
>reveicer class name *and* selector and not just by selector is the root
>of a lot of this trouble).

Ok, but I've always referred to them as simply object methods and
class  methods.  I see where you're going and you're probably right. 

>It is IMHO best to try and get the programmer to distiguish between instance
>objects and class objects. 

I've just avoided the problem by treating objects and being
instantiated from classes and not concern them with "class objects",
but I'm coming along to your POV insofar as your methodology does make
understanding of class methods more clear.

>Now they have (hopefully) enough knowledge to write the method.  
>Notice how we were careful to skirt the issue that even classes have classes. 

>You seem to have a basic grip on the
>notion of metaclasses.  Why would you state that *class methods*
>are accessable to all instances of the class?  

Because I made a mistake!  :) I forgot that we are discussing
Smalltalk.  In another language, you can access class methods from an
object by the use of "::class:someMethod()" syntax.  Likewise class
variables. In this other environment you can further restrict the
accessibility of  class vars and methods  in child classes by use of
the keyword "share".  I am still not far enough along in Smalltalk to
know to what extent they are utilitzed differently here. 

>>I'm not at all familiar with "cares-about".  What are its
>>characteristics?

>This relationship is the dependency relationship in VW.  I believe that
>the closest analogy in V would be the triggerEvent: group of methods.
>This idea is known as loose coupling.  One object cares about the state
>of another and would like to set up a relationship where the first object
>will notify it of changes in state.  But this should be done in such a 
>way that the first object *does not depend* on the other to actually
>be around.  This in VW model object have dependents, typically views.
>So when the state of the model changes, the model notifies its dependents
>of the change in state.  The model does not care if no dependents exist.
>The model does not care what the dependent does with the information.

>I brief study of the M(M)VC structure in VW should give you more than
>you even wanted to know about a workable(?) example of cares-about.

Barry, I'm not at all familiar with VW  - what do the initials mean?

I understand loose coupling,   "broadcasting", managers  and
cross-coupling.  This sounds like each object maintains a reference to
the other (or to a third "manager" for the purposes of notification.
Is this what you mean?

Thanks,

Larry
--





