Replying to my own post, how sad... "Alan Gauld" <[EMAIL PROTECTED]> wrote
> First we need a way to create objects since we dont have > classes...so we write a function that returns a dictionary. > We'll make it simple and have a message class that stores > a string and has a display method. > > def display(aMessage): > print aMessage['text'] > > def Message(theText): > theObject = {} > theObject['text'] = theText > return theObject Oops I lost the plot somewhere here, the create function should have been called createMessage and looked like: def createMessage(theText): theObject = {} theObject['text'] = theText theObject['display'] = display return theObject > Now we create a couple of instances and display them: > > m1 = createMessage('Good morning') > m2 = createMessage('Hello world') > > display(m1) > display(m2) And the display calls should have been via the dictionary: m1['display'](m1) m2['display'](m2) > Notice how we need to pass the instance that we want > to display into the display call? And that should make more sense and be closer to the true OOP version... > Now lets write the same thing using real OOP: > > class Message: > def __init__(self, theText): > self.text = theText > def display(self): > print self.text > > m1 = Message('Good morning') > m2 = Message('Hello world') > Message.display(m1) > Message.display(m2) > > If you compare the definition of the display function and > the definition of the display method can you see the similarity, > and the correspondence of self to aMessage? > > Now look at the two calls to display in the real OOP example. > Can you see the similarity to the calls to display in the non OOP > version? > > Again can you see the correspondence between the values > passed in to the function and the values passed via the class. > In both cases its m1,m2, ie the instances we created. > In both cases the function needs those values to know > which objects message it should print. > > Finally we have the more conventionalOOP notation for calling > methods: > > m1.display() > m2.display() > > These are exactly the same as the previous calls via the > Message class, but are more intuitive (once you start > feeling comfortable with OOP notation as used with strings > and the like) > > I've never tried explaining self with that set of examples so > it may have confused things even more! But maybe its more > conventional approach to functions v methods might make sense. > > The final caveat is that message dispatch gets more complex > when you factor in inheritance so the simple non OOP example > breaks down fairly quickly... > > HTH, > > > -- > Alan Gauld > Author of the Learn to Program web site > http://www.freenetpages.co.uk/hp/alan.gauld _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor