[Python-ideas] Composition over Inheritance

Soni L. fakedme+py at gmail.com
Sat Oct 28 21:46:37 EDT 2017



On 2017-10-28 11:31 PM, Koos Zevenhoven wrote:
> On Sat, Oct 28, 2017 at 11:24 PM, Soni L. <fakedme+py at gmail.com 
> <mailto:fakedme+py at gmail.com>>wrote:
>
>
>     On 2017-10-28 02:51 PM, Steven D'Aprano wrote:
>
>
>         You ignored my question: Is that the sort of thing you mean by
>         composition? If not, then what do you mean by it? This is not a
>         rhetorical question: I'm having difficulty understanding your
>         proposal.
>         It is too vague, and you are using terminology in ways I don't
>         understand.
>
>         Maybe that's my ignorance, or maybe you're using non-standard
>         terminology. Either way, if I'm having trouble, probably
>         others are too.
>         Help us understand your proposal.
>
>
>
> I have to say I'm almost impressed by the constructiveness of the 
> discussion, even though​ I still don't understand the point of all the 
> square brackets in the proposal.
>
>     With composition, you can have car.key.turn() call
>     car.ignition.start(), without having to add car to key or ignition
>     to key. You just have to put both in a car and they can then see
>     eachother!
>
>
> Here it's a bit confusing that the key is thought of as part of the 
> car. It's easy to imagine that an owner of two cars would want the 
> same key to work for both of them. Or that one car could have multiple 
> users with non-identical keys. I'm not sure if these things already 
> exist in real life, but if not, it's probably just a matter of time.
>
> But let's ignore this confusion for a moment, and imagine that the 
> example makes perfect sense. Now, it sounds like you want something 
> like namespacing for methods and attributes within a complicated 
> class. Maybe you could implement it using nested classes and 
> decorators to make sure 'self' is passed to to the methods in the way 
> you want. The usage might look roughly like:
>
> @namespacedclass
> class Car:
> @classnamespace
>     class ignition:
>         def start(self):
>              ...
>
> @classnamespace
>     class key:
>         def turn(self):
> self.ignition.start()
>
>
> Another concern regarding the example, however, is that this seems to 
> make it unclear what the public API of the car is. It looks like you 
> can just as easily drive the car without having the key: just call 
> car.ignition.start().

It's a crap example, yes.

But you should be able to do things like

car = object()
car[Engine] = SimpleEngine()
car.[Engine].kickstart() # calls kickstart method with an instance of 
SimpleEngine as `self`/first argument and `car` as second argument.
# etc

Which your decorator-based approach quite obviously doesn't let you.
>>
> -- Koos
>
>
> -- 
> + Koos Zevenhoven + http://twitter.com/k7hoven +

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171028/9d9c33b6/attachment-0001.html>


More information about the Python-ideas mailing list