[Edu-sig] more simmering debate...

[kirby urner]

I want to suggest that the much-used metaphor (by me included):

"class is a blueprint, with instances the buildings made from it"

(houses usually) is a good start, but not nuanced enough to take us all the
way to the end of our story.

These days I've taken a two pronged approach:  yes, OO is meant to model
how we think normally, about things with properties and behaviors.

"The language gets out of the way and lets you think in terms you're
already familiar with, from work" and such PR, some truth in it...

... However (big pause), OO also is it's own knowledge domain with its own
concepts and those are better faced directly and dealt with than dismissed
as mere noise.

The blueprint metaphor, in being so simple, is maybe too simple, and
therefore  dismissive, at least if left in place for too long.

So yes, OO has its cost, the knowledge domain that is OO with all its
twisted tails of multiple inheritance and the method resolution order.

But learning that little overhead is more than worth the price of admission
(the PR again).

The whole idea of inheritance, and of static and class methods, undermines
this simplistic beginning of "blueprint" and so could become corrosive
vectors of entropy (leaking sense), if not contained within more fitting
metaphors.

I like to say the class is a "mother ship" and serves as a kind of "home
base" or "platform".  How about an "amusement park"?

Each self brings its little __dict__ to the theme park, but all the "rides"
(the "stuff happening") are anchored in the class's __dict__.  The self
parameter is like an empty seat in a ride, which the rider's self then
fills.

This so-called "blueprint" is where the methods are happening, which is so
not what it's like in the case of houses.

The many instances (the selves) are but little bags of state, little "var
stashes" (uh oh, JavaScript creeping in... :-D).

Anyway, ya catch my drift, right?

If we over-stress the blueprint metaphor they'll not be as open minded
about blueprints having their own "batteries included" and doing stuff on
their own, no "selves" need apply in some cases (not all methods need a
self).

Literal blueprints don't light up and do stuff all on their own like that.

Our classes often behave a lot more like objects with a life of their own.

... and that's true of course as they're each instances of the type "type",
one more example of what that "bag o' tricks" we called 'a class' might
look like.

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160420/7ba70869/attachment.html>