Thanks. I think the example you're giving is certainly a reasonable reason to be able to still give unused arguments so we'll configure the rule so that arguments prefixed with an underscore (`_`) are allowed. However we're still going to remove all the existing unused arguments for the roll-out as we have no reliable way of telling which is which and believe that in general removing the arguments is a better cleanup than applying a prefix to everything.
On Wed, 29 Nov 2023 at 14:37, Marco Bonardo <[email protected]> wrote: > On Wed, Nov 29, 2023 at 2:11 PM Dave Townsend <[email protected]> > wrote: > >> >> I sometimes specify arguments even if they are not used, especially when >>> refactoring code and adding new arguments that avoid the consumer fetching >>> things in more exotic ways. Unless I update all consumers with the new >>> argument, people are used to the previous signature and may not notice the >>> change, then new exotic fetches are added. >>> It's surely something that the review process should catch, but it's not >>> a given. >>> >> >> Can you explain this further, I'm not sure I understand what you're >> saying. >> > > Before refactoring: > => file1.js > interfaceImpl(arg1, arg2) { > let something = exotic_way_to_get_something(); > let other = something.do(); > return arg1 + arg2 + other; > } > => file2.js > interfaceImpl(arg1, arg2) { > return arg1 + arg2; > } > > After refactoring, with the new no-unused-args: > => file1.js > interfaceImpl(arg1, arg2, something) { > let other = something.do(); > return arg1 + arg2 + other; > } > => file2.js > interfaceImpl(arg1, arg2) { > return arg1 + arg2; > } > > Now DeveloperB needs `something` in file2, they know the Interface, but > they don't know `something` is now available as argument, so they end up > writing: > => file.js > interfaceImpl(arg1, arg2) { > let something = exotic_way_to_get_something(); > let other = something.do(); > return arg1 + arg2 + other; > } > > In this case I prefer to add the new unused argument to all the > interfaceImpl instances during the refactoring, so when DeveloperB arrives, > they will find: > => file.js > interfaceImpl(arg1, arg2, something) { > return arg1 + arg2; > } > > that makes immediately obvious `something` can now be used directly. > I admit this may be considered an edge case, and most people are unlikely > to do it (for which it's a good idea to check the interface definition > every time), but I found it handy. > > In all honesty, I was mostly wondering if unused arguments come with a > performance cost. > I don't have too strong feelings overall, as while I'd appreciate a way > out (like the _ prefix), I also see how it could be easily abused. > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAPMxTNr06aXoPkQ4ojTfsVJGUj-_2rU9YApszCwS9brXJZ1T5w%40mail.gmail.com.
