> "contract" is a better term, IMO, since it's already used in CS (as in > Eiffel), and describes the situation more correctly: *behavior* rather > than *signature*. > "ability" just doesn't seem right to me: my class is not *able* to be a > set, > it *behaves* like a set. it follows the set contract, not "ability"
I avoided suggesting the word "contract" instead of "ability" because I do not want people to think that the notion is somehow connected to Eiffel contracts. As Guido (I think) pointed out, it's closer to Haskell typeclasses. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
