3 ms·

That's right. The reason for this is that it's a lot of boilerplate if you were to require listing every relevant Impl block as a superclass of your struct. I a

That's right. The reason for this is that it's a lot of boilerplate if you were to require listing every relevant Impl block as a superclass of your struct. I also, as a bonus, like enforcing a consistent class naming style.

Diggsey 5y ago
That's not a great reason to use strings to identify classes though... Why not just give `Impls` a special attribute: class ExampleImpl(Foo, metaclass=Impl): target = Bar Or do the entire thing via a decorator: @impl_for(Bar) class ExampleImpl(Foo): pass ?
- xrudelis 5y ago
  I think these are all equally good. The Impl's name should never need to be referred to, so ultimately the choice should be based on what's easiest to read. EDIT: actually, your examples wouldn't work as-is, since it would result in circular references (something Python isn't well-equipped to handle). Your target names would need to be strings instead of the actual class. EDIT2: I have updated the code to allow for another syntax: class AnyImplNameIWant(MyTrait, metaclass=Impl, target="MyStruct"): ... It would certainly be nicer if `MyStruct` didn't need to be a string of course. I really think these options are mostly down to taste, so I'll just have to trust that this alternative reads sufficiently more nicely.
  - aldanor 5y ago
    Correction: what's easiest to read to someone who hasn't carefully read every single line of your library. Verbosity is not always bad, if it yields clarity.
- luoc 5y ago
  I'd go for the decorator approach for its explicitness. It reads like plain English without having a deeper understanding of the concepts. Also, it does not pollute the implementors namespace. Even if one argues for the naming convention solution, one has to admit that it causes confusion for most people stumbling over it for the first time.
OJFord 5y ago
Why not use a decorator for that? @impl(Sheep, Animal) class ImplAnimalForSheep: ... or something? It probably needn't even be a separate class - just decorate the relevant methods (or the `Sheep` class itself) `@impl(Animal)` and check the necessary ones are implemented on instantiation.

Diggsey 5y ago

That's not a great reason to use strings to identify classes though... Why not just give `Impls` a special attribute: class ExampleImpl(Foo, metaclass=Impl): target = Bar Or do the entire thing via a decorator: @impl_for(Bar) class ExampleImpl(Foo): pass ?

xrudelis 5y ago
I think these are all equally good. The Impl's name should never need to be referred to, so ultimately the choice should be based on what's easiest to read. EDIT: actually, your examples wouldn't work as-is, since it would result in circular references (something Python isn't well-equipped to handle). Your target names would need to be strings instead of the actual class. EDIT2: I have updated the code to allow for another syntax: class AnyImplNameIWant(MyTrait, metaclass=Impl, target="MyStruct"): ... It would certainly be nicer if `MyStruct` didn't need to be a string of course. I really think these options are mostly down to taste, so I'll just have to trust that this alternative reads sufficiently more nicely.
- aldanor 5y ago
  Correction: what's easiest to read to someone who hasn't carefully read every single line of your library. Verbosity is not always bad, if it yields clarity.
luoc 5y ago
I'd go for the decorator approach for its explicitness. It reads like plain English without having a deeper understanding of the concepts. Also, it does not pollute the implementors namespace. Even if one argues for the naming convention solution, one has to admit that it causes confusion for most people stumbling over it for the first time.

OJFord 5y ago

Why not use a decorator for that? @impl(Sheep, Animal) class ImplAnimalForSheep: ... or something? It probably needn't even be a separate class - just decorate the relevant methods (or the `Sheep` class itself) `@impl(Animal)` and check the necessary ones are implemented on instantiation.