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

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

Re: Composition instead of inheritance

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

Contents

  Re: Composition instead of inheritance Carl Banks <pavlovevidence@gmail.com> - 2011-04-28 15:35 -0700
    Re: Composition instead of inheritance Ethan Furman <ethan@stoneleaf.us> - 2011-04-28 18:43 -0700
      Re: Composition instead of inheritance Ben Finney <ben+python@benfinney.id.au> - 2011-04-29 13:44 +1000
        Re: Composition instead of inheritance Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-04-29 11:23 +0200
    Re: Composition instead of inheritance MRAB <python@mrabarnett.plus.com> - 2011-04-29 03:14 +0100
    Re: Composition instead of inheritance James Mills <prologic@shortcircuit.net.au> - 2011-04-29 13:16 +1000
    Re: Composition instead of inheritance Dan Stromberg <drsalists@gmail.com> - 2011-04-28 20:58 -0700
      Re: Composition instead of inheritance Ben Finney <ben+python@benfinney.id.au> - 2011-04-29 14:14 +1000
    Re: Composition instead of inheritance John Nagle <nagle@animats.com> - 2011-04-28 22:10 -0700
    Re: Composition instead of inheritance Ethan Furman <ethan@stoneleaf.us> - 2011-04-29 13:39 -0700

#4276 — Re: Composition instead of inheritance

On Thursday, April 28, 2011 10:15:02 AM UTC-7, Ethan Furman wrote:
> For anybody interested in composition instead of multiple inheritance, I 
> have posted this recipe on ActiveState (for python 2.6/7, not 3.x):
> 
> http://code.activestate.com/recipes/577658-composition-of-classes-instead-of-multiple-inherit/
> 
> Comments welcome!

That's not what we mean by composition.  Composition is when one object calls upon another object that it owns to implement some of its behavior.  Often used to model a part/whole relationship, hence the name.

The sorts of class that this decorator will work for are probably not the ones that are going to have problems cooperating in the first place.  So you might as well just use inheritance; that way people trying to read the code will have a common, well-known Python construct rather than a custom decorator to understand.

If you want to enforce no duplication of attributes you can do that, such as with this untested metaclass:

class MakeSureNoBasesHaveTheSameClassAttributesMetaclass(type):
    def __new__(metatype,name,bases,dct):
        u = collections.Counter()
        for base in bases:
            for key in base.__dict__.keys():
                u[key] += 1
        for key in dct.keys():
            u[key] += 1
        if any(u[key] > 1 for key in u.keys()):
            raise TypeError("base classes and this class share some class attributes")
        return type.__new__(metatype,name,bases,dct)
 

Carl Banks

[toc] | [next] | [standalone]

#4283

Carl Banks wrote:
> That's not what we mean by composition.  Composition is when one object
 > calls upon another object that it owns to implement some of its behavior.
 > Often used to model a part/whole relationship, hence the name.

Hmmm. Okay -- any ideas for a better term?  Something that describes 
taking different source classes and fusing them into a new whole, 
possibly using single-inheritance... Frankenstein, maybe?  ;)


> The sorts of class that this decorator will work for are probably not
 > the ones that are going to have problems cooperating in the first place.
 > So you might as well just use inheritance; that way people trying to read
 > the code will have a common, well-known Python construct rather than a
 > custom decorator to understand.

 From thread 'python and super' on Python-Dev:
Ricardo Kirkner wrote:
 > I'll give you the example I came upon:
 >
 > I have a TestCase class, which inherits from both Django's TestCase
 > and from some custom TestCases that act as mixin classes. So I have
 > something like
 >
 > class MyTestCase(TestCase, Mixin1, Mixin2):
 >    ...
 >
 > now django's TestCase class inherits from unittest2.TestCase, which we
 > found was not calling super.

This is the type of situation the decorator was written for (although 
it's too simplistic to handle that exact case, as Ricardo goes on to say 
he has a setUp in each mixin that needs to be called -- it works fine 
though if you are not adding duplicate names).

~Ethan~

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

#4291

Ethan Furman <ethan@stoneleaf.us> writes:

> Carl Banks wrote:
> > That's not what we mean by composition. Composition is when one
> > object calls upon another object that it owns to implement some of
> > its behavior. Often used to model a part/whole relationship, hence
> > the name.
>
> Hmmm. Okay -- any ideas for a better term? Something that describes
> taking different source classes and fusing them into a new whole,
> possibly using single-inheritance... Frankenstein, maybe? ;)

(Remember that Frankenstein was not the monster, but the scientist.)

“Hybrid”?

-- 
 \      “If sharing a thing in no way diminishes it, it is not rightly |
  `\      owned if it is not shared.” —Augustine of Hippo (354–430 CE) |
_o__)                                                                  |
Ben Finney

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

#4301

Ben Finney wrote:
> Ethan Furman <ethan@stoneleaf.us> writes:
>
>   
>> Carl Banks wrote:
>>     
>>> That's not what we mean by composition. Composition is when one
>>> object calls upon another object that it owns to implement some of
>>> its behavior. Often used to model a part/whole relationship, hence
>>> the name.
>>>       
>> Hmmm. Okay -- any ideas for a better term? Something that describes
>> taking different source classes and fusing them into a new whole,
>> possibly using single-inheritance... Frankenstein, maybe? ;)
>>     
>
> (Remember that Frankenstein was not the monster, but the scientist.)
>
> “Hybrid”?
>
>   
Actualy this story is about the villagers being the monsters :o)

JM

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

#4287

On 29/04/2011 02:43, Ethan Furman wrote:
> Carl Banks wrote:
>> That's not what we mean by composition. Composition is when one object
>  > calls upon another object that it owns to implement some of its
> behavior.
>  > Often used to model a part/whole relationship, hence the name.
>
> Hmmm. Okay -- any ideas for a better term? Something that describes
> taking different source classes and fusing them into a new whole,
> possibly using single-inheritance... Frankenstein, maybe? ;)
>
[snip]
Fusing/fusion? Compounding?

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

#4290

On Fri, Apr 29, 2011 at 11:43 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
> Hmmm. Okay -- any ideas for a better term?  Something that describes taking
> different source classes and fusing them into a new whole, possibly using
> single-inheritance... Frankenstein, maybe?  ;)

I'd have to say that this is typical of MixIns

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

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

#4293

On Thu, Apr 28, 2011 at 3:35 PM, Carl Banks <pavlovevidence@gmail.com> wrote:
> On Thursday, April 28, 2011 10:15:02 AM UTC-7, Ethan Furman wrote:
>> For anybody interested in composition instead of multiple inheritance, I
>> have posted this recipe on ActiveState (for python 2.6/7, not 3.x):
>>
>> http://code.activestate.com/recipes/577658-composition-of-classes-instead-of-multiple-inherit/
>>
>> Comments welcome!
>
> That's not what we mean by composition.  Composition is when one object calls upon another object that it owns to implement some of its behavior.  Often used to model a part/whole relationship, hence the name.

It's a pretty old idea, that seems to be getting revived in a big way
all of a sudden.  Perhaps the Java people just rediscovered it?

In a Software Engineering class using Ada, the teacher called it
"Structural Inclusion", and of course it was an important concept in
Ada, because Ada had no inheritance.  This was in 1989-1990.

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

#4295

Dan Stromberg <drsalists@gmail.com> writes:

> On Thu, Apr 28, 2011 at 3:35 PM, Carl Banks <pavlovevidence@gmail.com> wrote:
> > That's not what we mean by composition.  Composition is when one
> > object calls upon another object that it owns to implement some of
> > its behavior.  Often used to model a part/whole relationship, hence
> > the name.
>
> It's a pretty old idea, that seems to be getting revived in a big way
> all of a sudden. Perhaps the Java people just rediscovered it?

I think it's more that people keep re-discovering how irredeemably messy
multiple inheritance is, and finding that object composition is better
in most cases :-)

-- 
 \      “There's a fine line between fishing and standing on the shore |
  `\                            looking like an idiot.” —Steven Wright |
_o__)                                                                  |
Ben Finney

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

#4298

On 4/28/2011 3:35 PM, Carl Banks wrote:
> On Thursday, April 28, 2011 10:15:02 AM UTC-7, Ethan Furman wrote:
>> For anybody interested in composition instead of multiple
>> inheritance, I have posted this recipe on ActiveState (for python
>> 2.6/7, not 3.x):
>>
>> http://code.activestate.com/recipes/577658-composition-of-classes-instead-of-multiple-inherit/
>>
>>
>>
Comments welcome!
>
> That's not what we mean by composition.  Composition is when one
> object calls upon another object that it owns to implement some of
> its behavior.  Often used to model a part/whole relationship, hence
> the name.

     The distinction isn't that strong in Python, where an object
can't be part of another object.  Object fields are references, not
the objects themselves.

     In C++, you really can have an object as a field of an enclosing
object.  The inner object's destructor will be called first.
Destructors and ownership tend not to be too important in Python,
because storage management is automatic.
					
				John Nagle

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

#4323

James Mills wrote:
> On Fri, Apr 29, 2011 at 11:43 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
>> Hmmm. Okay -- any ideas for a better term?  Something that describes taking
>> different source classes and fusing them into a new whole, possibly using
>> single-inheritance... Frankenstein, maybe?  ;)
> 
> I'd have to say that this is typical of MixIns

Yes, but it's designed to be used when Mixins fail because of MI issues 
(see my reply to Carl for an example).

Maybe Integrate?

~Ethan~

[toc] | [prev] | [standalone]

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

csiph-web