https://pantsbuild.org/ logo
#development
Title
# development
w

wide-midnight-78598

11/15/2022, 1:51 PM
Before I go too far down the rabbit-hole, and I vaguely remember asking about this like 6 months ago - I see that we use Mixins and generally composable functionality in certain places, but is there anything preventing its usage in Subsystems (or anything that would end up in the rule graph)? The specific use case I'm thinking of right now is the
XYZToolBase
that I see in Python and in the JVM, which adds versions, lockfiles, etc to subsystems. However, the code is copied/unique for those two classes, and the NodeJS backend will add another, and so on. Has there been any consideration in the past about extracting some of that functionality into a set of composable interfaces, or composable functionality, for the sake of being able to quickly setup a common user-API (and then maybe changing implementation per backend, if needed)?
For example:
Copy code
class AwesomeJavascriptTool(VersionMixin, Subsystem): 
    ...

or

class AwesomeJavascriptTool(NodeToolBase): ...

class NodeToolBase(Versionable, Lockable, Subsystem): ...
While each backend has their own nuances and implementations, there are a lot of shared semantic concepts
b

bitter-ability-32190

11/15/2022, 2:36 PM
No technical reasons. I personally like mixins. From what I've been told V1 was inheritance-heavy to a fault. So I think that explains the hesitation for it in v2. Although mixins are a way to do composable inheritance, and I think is a happy middle ground
👍 1
w

wide-midnight-78598

11/15/2022, 2:37 PM
hesitation for it in v2
Hesitation for inheritance or composition?
b

bitter-ability-32190

11/15/2022, 2:38 PM
Inheritance. @hundreds-father-404 was providing the context so I'll just let it come from the horses mouth 😛
👍 2
w

wide-midnight-78598

11/15/2022, 2:39 PM
Depending on the language, I use different paradigms, but I'm not on the Swift/iOS bandwagon of "composition is life, you should never inherit", but case by case 🤷
Subsystems, specifically, are where I see value right now - to at least bring the backends/plugins to similar levels of configurability, while not re-writing copying too much code.
b

bitter-ability-32190

11/15/2022, 2:44 PM
I completely agree 🙂
h

hundreds-father-404

11/15/2022, 4:45 PM
I'm more in favor of mixins than traditional inheritance One of the biggest case studies of what we thought went wrong in v1 was
PythonToolBase
. For a long time, it was resulting in registering options that didn't make any sense for tools like
setup-py
, e.g.
--entry-point
. We had to redesign the base class so that users opt-in to those options, rather than being on by default That's my main concern, when things become too implicit and you end up registering a bunch of options you didn't realize. Mixins are one way to reduce that risk, and having class properties to conditionally register options is another (but not type-safe)
👍 1
w

wide-midnight-78598

11/15/2022, 4:49 PM
Im not a fan of the class properties thing - feels almost (but not quite) like a code smell to me
b

bitter-ability-32190

11/15/2022, 4:49 PM
(Yeah I need to fix the type-safety of plugin options. Never got around to thinking that one through)
w

wide-midnight-78598

11/15/2022, 4:49 PM
There are legit cases, though, which is fair
b

bitter-ability-32190

11/15/2022, 4:50 PM
Technically the classvars aren't type-enforced (from what I;ve seen)