Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #91027 > unrolled thread

different types of inheritence...

Back to article view | Back to comp.lang.python

Contents

  different types of inheritence... zipher <dreamingforward@gmail.com> - 2015-05-21 19:14 -0700
    Re: different types of inheritence... zipher <dreamingforward@gmail.com> - 2015-05-26 07:57 -0700
      Re: different types of inheritence... Michael Torrie <torriem@gmail.com> - 2015-05-26 14:52 -0600
        Re: different types of inheritence... zipher <dreamingforward@gmail.com> - 2015-05-27 11:12 -0700
      Re: different types of inheritence... Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-26 15:12 -0600

#91027 — different types of inheritence...

Still considering distinguishing between different types of inheritance.  

Apart from object composition or mix-in style, I want to illustrate something regarding the "arrow" of inheritance.

class super_dict(dict):

    def __init__(self, init={}, default_value=0, collision_function=None):
       *expands what dict can do*

    def get_default(self):  #stupid method to illustrate a point
       return self._default_value

class specialized_dict(dict):

    def update(self, other):
        *change the behavior of how updates work*

    def setdefault(self, key, value):
        if key=sentinel:
            self[key]=0
        else:
            self[key]=value

These look like the standard is-a inheritance, but they are very different.  

The first goes upwards, making a super-class, the other drills downwards and makes dict more specialized.  The former expands on the capability and the API, the latter keeps the exact API but modifies the method behaviors.  The former becomes a more general type, the latter becomes a more specific type.

Steven D'Aprano was arguing a couple of years ago that there is no difference, one can simply turn the inheritance diagram upside-down.  But here it can be seen that that's not an option

Anyone else see the significance?  Sorry to be a PITA...

Mark

[toc] | [next] | [standalone]

#91248

> Apart from object composition or mix-in style, I want to illustrate something regarding the "arrow" of inheritance.
> 
> class super_dict(dict):
> 
>     def __init__(self, init={}, default_value=0, collision_function=None):
>        *expands what dict can do*
> 
>     def get_default(self):  #stupid method to illustrate a point
>        return self._default_value
> 
> class specialized_dict(dict):
> 
>     def update(self, other):
>         *change the behavior of how updates work*
> 
>     def setdefault(self, key, value):
>         if key=sentinel:
>             self[key]=0
>         else:
>             self[key]=value

Okay, perhaps I wasn't being clear.... 

THESE OBJECTS HAVE THE SAME CLASS *SYNTAX*, BUT COMPLETELY DIFFERENT *SEMANTICS*.

Comprende?  I'm not trying to be cryptic here.  This is a bit of OOP theory to be discussed.

Mark

[toc] | [prev] | [next] | [standalone]

#91265

On 05/26/2015 08:57 AM, zipher wrote:
> Comprende?  I'm not trying to be cryptic here.  This is a bit of OOP
> theory to be discussed.

No, sorry.  Maybe an actual example (with use case) would spur discussion.

[toc] | [prev] | [next] | [standalone]

#91317

On Tuesday, May 26, 2015 at 3:53:25 PM UTC-5, Michael Torrie wrote:
> On 05/26/2015 08:57 AM, zipher wrote:
> > Comprende?  I'm not trying to be cryptic here.  This is a bit of OOP
> > theory to be discussed.
> 
> No, sorry.  Maybe an actual example (with use case) would spur discussion.

In the first example, super_dict changes the behavior of <dict> *for the user*, expanding the API, but keeping all the prior method behaviors the same.  

In the second example, specialized_dict changes the behavior in the machine -- the API stays the same so the user of the code just gets new benefits from whatever the specialized_dict is improving internally *without changing his/her code*.  It's a drop-in replacement.

In other words, the second class changes the INTERNALS of <dict>.  While the first class changes the *externals* of <dict>.  Yet they both use the same class definition, but semantically are completely different.  It's TWO different definition of IS-A relationship.  Two definitions of the word "is".

m

[toc] | [prev] | [next] | [standalone]

#91266

On Tue, May 26, 2015 at 2:52 PM, Michael Torrie <torriem@gmail.com> wrote:
> On 05/26/2015 08:57 AM, zipher wrote:
>> Comprende?  I'm not trying to be cryptic here.  This is a bit of OOP
>> theory to be discussed.
>
> No, sorry.  Maybe an actual example (with use case) would spur discussion.

Better yet, ignore the troll.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web