[Edu-sig] more simmering debate...

[Carl Karsten]

> 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"?
...

I don't think any of that is any better.

When explaining OOP, I have two points I try to drive home.

0. you can do anything in any language any way you please.  OOP does not
give you any new capabilities,  it is just a way of keeping your code
organized and readable.

1. I describe a parent class and some of the subclasses used in my video
processing system

parent: find a list of videos to work on, iterate over the list,
self.work() on each one.
work is defined in the subclasses:

subclass 1 - encode
subclass 2 - upload
subclass 3 - email the URL to the presenter






On Wed, Apr 20, 2016 at 3:53 PM, kirby urner <kirby.urner at gmail.com> wrote:

>
> 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
>
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> https://mail.python.org/mailman/listinfo/edu-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160420/fdb965a7/attachment-0001.html>