Abc and Protocols are not the same, though. The protocol is met when all methods are implemented with the expected signature. Abstract base classes require you to opt in to be considered an Implementation of some interface. Both have different use cases. Protocols are much more fragile.
I wouldn’t say Protocols are more “fragile”… They’re more strict.
The opposite is true. If you have two interfaces that contain methods with the same name, then they have the same
typing.Protocol. It is not possible to specify preconditions or contracts, as you would with abc.
I need to move away from using inheritance in my Python. I’ve been using Rust exclusively for the past year and it’s definitely going to affect how I write code in other languages.
“If only I could make this a
trait…”Yes!
No. Duck types (including virtual subclasses) considered harmful; use real inheritance if your language doesn’t provide anything strictly better.
It is incomparably convenient to be able to retroactively add “default implementations” to interface functions (consider for example how broken
readintois in Python). Some statically-typed languages let you do that without inheritance, but no dynamically-typed language can.This reads more as a rant against inheritance (without any explanation whatsoever) than a legitimate argument.
Personally I prefer functional architectures + callbacks (better) / closures (tolerable),they tend to scale a bit better.
If a a dog needs to eat, then invoke the eat function with dog data and the dog eat function.
Explicit (this data is dog so I feed it with the dog eat function) vs implicit (I have no idea, I ask my data to eat as it pleases).
Explicit design tends to have fewer bugs my conjecture. Protocols are a halfway point, at least you know “hey this thing eats … uh … something.”
However, if doing that, just take it all the way - systems are better explicitly linking a verb to a noun vs assuming the noun knows how to verb.
It is also easier to test and debug.
