Re: Well, obviously ...
> I started off thinking of Objects as structures with functions built in, and the rest was straightforward
That's true. But the way OO is taught in schools, you can end up swallowin too much Koolaid and get tied up in unproductive knots and arguments.
Suppose you have a function which acts on a Foo and a Bar. Should it be a method of Foo, or a method of Bar?
If you want to make an object Baz which makes use of the functionality of Foo, should it be a subclass of Foo or contain a reference to an instance of Foo?
Is a Square a restricted type of Rectangle, or is a Rectangle an enhancement to Square?
Polymorphism is one of those things which is apparently inherent to OO, but in practice rarely used. But it always makes it hard to follow the flow of code. e.g.
def foo(o):
o.bar()
Where in your source code is method 'bar' defined? Whereas:
def foo(o):
Mymodule.bar(o)
is completely unambiguous.
When you go back to simple procedures and data arguments, these problems go away.
Biting the hand that feeds IT
