https://pantsbuild.org/ logo
Join Slack
Powered by
<@U04S45AHA>: i followed up on the explicit getter...
# development
w
@enough-analyst-54434: i followed up on the explicit getter thing
e
Yeah.
I have always liked this better, but I'm looking for what you all think.
w
which isn’t great. i think i thought that there would be more opportunity to give better names, but in this case at least it was boilerplate
because you’re probably going to name it a variant of the types
or that would be a convention
but un-enforced
e
I'll let you all decide. I'd happily trade the ast parsing for explicit injection like that.
w
from a user perspective, i don’t see the benefit. it’s simpler to implement of course, and i haven’t touched that code in a long time, so maybe that’s justified. but.
e
As a clearly odd user, I like that I have just rules now and my dependencies are explicit on those rules (more clear you're asking for a "rule" when named GetRule). It's clear others don't feel this way I think.
w
i think the flip side of that is that “my function has a lot of arguments” is maybe not something that users count as a benefit… perhaps they would prefer global singletons, for example.
you removed most of the boilerplate of having function arguments by killing the 
@rule([*selectors])
syntax, which was awesome.
e
I think my function has alot of arguments is a good smell pushback.
It should be easier to factor out functions.
w
yea. and without all of the dependencies of the function being literally in the arguments, you have to say it differently… “lots of dependencies” rather than “lots of arguments”
e
Basically this all reads exactly like constructor DI in java to me with Guice and that was exactly a good smell to react to.
This rule does way too much.
w
i just think that in this case the cost of the forced boilerplate is higher than the benefit. someone sniffing for “rule is too big” can still count args+gets to apply their lint
e
k
Open in Slack
PreviousNext
Powered by