On Thu, Jul 16, 2015 at 6:50 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> On 2015-07-15 6:47 PM, Jeff Gilbert wrote: > >> "Arg warts improve backtracking for debugging" >> Regardless of the validity of "Arg warts help illustrate information >> flow", the use-case of backtracking to 'origin' of aFoo is also >> unconvincing, since you'd only need to go back once more than previously >> before moving once back 'up'. Either way sounds eminently automateable. >> -> No practical change, thus irrelevant. >> > > I don't understand what you're saying here at all. It seems that you're > saying that this use case is not interesting to you, and that's OK, but > that doesn't make it irrelevant. :-) > Not at all! Rather, that either way it would be workable. The tiny extra bit of effort it would take without aFoo is completely solved by automation, and if this is a common enough use-case for this tiny extra bit of effort to matter, it should *already* have been automated. Thus I don't have a ton of sympathy for making a readily-automateable process require differentially more effort without automation. > > "It's hard to implement" >> This is irrelevant for new code, and bulk-change is feasible once we have >> -Wshadow. (which isn't too hard. We shouldn't have shadowing in our code >> anyway, so we want -Wshadow regardless of this discussion) Besides, a >> number of our internal projects and modules already don't have it, so it's >> free for them. >> -> Non-trivial, but not too hard to implement. >> > > The "isn't too hard" part of the above is factually incorrect. See bug > 563195 for why. > I have read it, and it doesn't seem insurmountable. Just because it's not free doesn't make it 'too hard'. I am naturally willing to work on this myself. > > So, when you say "I like aFoo because it lets me know which vars are >> args", >> is there any un-touched-on aspect of the information "this var is an >> argument" that is useful to know? How does every other project survive >> without it? >> > > Given Benjamin's response, there is really no point in arguing over this > any more, but just as a thought exercise: is there anything that would > convince you that this is useful for some people? There's only no point here if Benjamin's proposal carries! Besides, this discussion is certainly a subset of the boil-the-ocean discussion. If aFoo is truly valuable, then removing it via Google Style would hurt us just as removing it a la carte would. What could convince me? Reasoned and consistent arguments, perhaps examples or anecdotes where aFoo really came in handy that wouldn't have been covered under general good code style. Maybe someone might have done a study on this style. Maybe there are other large projects which use this style. Tautologically: Convincing arguments! > I would expect having those people tell you that it's useful for them > should be a good enough reason to assume that it is! > Especially as part of standards body, I'm perfectly fine with dismissing requests for things people claim to want, but can't provide sufficient reasoning for, [1] or likewise being unable to argue my own case successfully. I'm well-acquainted with being convinced to change my position through discussion and debate, and also with convincing others. (or not!) This is why we have these discussions! Claims are not substantiated simply because people claim them to be true. We need to lay the reasons on the table and then weigh them, as without reasons, choices are arbitrary. Sometimes we even need to do it more than once, as time changes things. (even if people hate doing this!) We may find no need for change, or we may instead find we can change for the better. [1]: To be clear, "sufficient reasoning" can definitely include "culture", "harsh realities", "pragmatism", and other such things. They are not all granted the same gravity, but they all contribute. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
