[Tutor] associating two objects without ORM and processing a text file

[Alan Gauld]

On 12/02/13 01:34, Steven D'Aprano wrote:

> If the class keeps a list of all instances, then the class method
> could walk the list and operate on each instance in turn. (But why
> would you do that?)

Because its how classes work in some languages (like smalltalk).
The class object represents all instances of the class.

> Although class methods could do anything, it is hard to think of
> actually useful things for them to do apart from being used as a
> constructor.

Again its the norm in Smalltalk apps to implement electors(searches) and 
other class wide operations in the class methods. Most Smalltalk classes 
have at least 5 or 6 class methods.

>> Which is to say a subset of the class Book.
>> Therefore quite reasonably a class method.
>
> Just a minute, I think that is completely wrong. A Book is not a set,
> so how can you have subset of it?

A Book is an instance of the class Book.
Book is a class of object encompassing all books.
So returning a subset of all instances of the class is normal class 
method behaviour.

> What is a subset of "Pride and Prejudice"? Perhaps chapter 5.

That might be a chapter or two? But Pride and Prejudice is not the class 
Book, it's an instance of Book.

> There are more problems with this idea that you query the Book to get
> a list of books by some author. Suppose you did this:
>
> prpr = Book("Pride and Prejudice", "Jane Austin")
> prpr.list_by_author()

No, you don't query the instance, you should query the class.

Book.list_by_author()   # -> a dict of lists keyed by author name?

(One of the unfortunate features of Python's implementation of
class methods is that you can call them from an instance which
doesn't really make sense! IMHO)

> Now *each and every* book is responsible for tracking all the other
> books by the same author. This is a lousy design. Even worse:
>
> prpr.list_by_author("Jane Austin")
>
> since now books are responsible for tracking ALL books by ALL authors,

Which is why it should be a class method not an instance one.
And in the real world we'd do that by building class methods
querying a database.

> Of course, books should know their own author, not the authors of other
> books, but authors should know all their own books:

instances should, I agree.

The Book class should know about all books in the class.

> First off, by convention the first argument to a class method should be
> called "cls", not "self".

Yes, my bad.
Although it is of course only a Python convention.

> Secondly, here you are relying on a mysterious global "config", which
> points to a bookfile. What does this have to do with a book?

The storage mechanism is an implementation detail. In Smalltalk its part 
of the infrastructure of the runtime.

> - Does a nail keep track of the packet it came from?

No, but the nail factory may keep track of the nails it
produces, or at least the batches...

> - Why should a book keep track of the catalog it was listed in?

A book wouldn't. but the Book class might.

> The rest of the method's design is also poor. You have already read
> the file once, to get the initial set of books. So why read the file
> again, every time you want to get some piece of information.

This I agree with. It would be better to persist the data somewhere for 
a small dataset.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/