https://pantsbuild.org/ logo
Join Slack
Powered by
<https://pantsbuild.slack.com/archives/C0D7TNJHL/p...
# development
a
w
thanks... that looks handy.
a
i have another extension for using unions as return types that i'm less certain about / still working on
w
i'll probably review later this week, but it would be good to motivate it via #4535 or something.
ie, let's ensure that it is necessary for something
a
it's for 
--query
, which uses it https://github.com/pantsbuild/pants/pull/7350
it's not necessary, it's syntax sugar
w
ok, but the target API isn't finalized, so it's not clear what types 
--query
should be operating on
not trying to couple those problems, but trying to avoid adding new syntax unless it proves to be necessary for the Target API, which might just use plain-jane base classes (unknown)?
a
ok, but the target API isn't finalized, so it's not clear what types 
--query
should be operating on
is this an argument against investigating 
--query
? because the 
@union
params in the case of 
--query
serve directly to decouple the objects 
--query
acts on from the underlying target API unless i'm mistaken
w
if query could operate on super classes, and the Target API uses super classes, then the new syntax would be extraneous
i'm not trying to block query. trying to ensure that we set a high usefulness bar for new syntax.
a
if query could operate on super classes, and the Target API uses super classes, then the new syntax would be extraneous
i don't understand what "super classes" is referring to here?
also, this definitely is not new syntax whatsoever, it’s incredibly forwards compatible
Open in Slack
PreviousNext
Powered by