https://pantsbuild.org/ logo
Join Slack
Powered by
Before I go too far down the rabbit-hole, and I va...
# development
w
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
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
hesitation for it in v2
Hesitation for inheritance or composition?
b
Inheritance. @hundreds-father-404 was providing the context so I'll just let it come from the horses mouth 😛
👍 2
w
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
I completely agree 🙂
h
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
Im not a fan of the class properties thing - feels almost (but not quite) like a code smell to me
b
(Yeah I need to fix the type-safety of plugin options. Never got around to thinking that one through)
w
There are legit cases, though, which is fair
b
Technically the classvars aren't type-enforced (from what I;ve seen)
Open in Slack
PreviousNext
Powered by