> If verb, define a method, and capture the key arguments in a clear API. >
Note: Sometimes a verb might not imply arguments. E.g. myheart.beat() makes sense as a verb if it's supposed to simulate a beat. A rule of thumb might be: if it's a verb, it makes sense to do it over and over, e.g. myheart.beat(10) also makes sense. Verbs are doings. On the other hand, myheart.weight would seem more noun-like, even if it changes over time. I suppose I could just as well think of attributes as adjectives (nouns go with 'state'). Anyway, the more general point is: it's the knowledge domain that should determine the API, and this often means mimicking real world objects -- e.g. trying to be "like" a heart. I don't believe in a philosophy that insists on making it all uniform (e.g. either all attributes or all methods), irrespective of how things are in reality. In my Triangle class, it made sense for sides a,b,c to be come across as attributes, and likewise angles A,B,C. Likewise area and perimeter. But if I rotate it by 45 degrees, that seems like a verb, likewise if I translate or scale it. It's my common sense notion of a triangle, its properties, its capabilities, that drives my API, i.e. it's the knowledge domain, not so much Python. And yes, there's room for judgment and different APIs, depending on who does the programming and who represents the knowledge domain. Kirby _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
