Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
enable auto-testing of problems #9
When I append the following to
… and run
Haven't got time to dig into the detail so I can't offer any suggestions regarding the errors and testing process but will review later this evening.
I think it's probably best to create a new test script which focuses on testing this functionality in isolation before doing integration tests with
Could I ask that you rename
ex_autotest() and rename the test argument in fetch_problem() to
I'm planning to update all exported functions to begin with the prefix
ex_ since I think this is useful in terms of UX. Will make it easier to find
exercism functions with autocomplete when the package is loaded.
And I'd also like to distinguish this 'auto testing' with the usual manual testing. Especially since I'd also like to add a manual testing helper to the package (which can mitigate the need to switch working directories when sourcing the provided test scripts directly).
Is there some background reading you can recommend about this prefixing? Noticed it in
IMHO, in an increasingly crowded namespace, prefixing one's own function names is overall less useful, than keeping one's own namespace clean and clear.
The catalyst for me in this case was an issue @jennybc raised here that I stumbled upon earlier this year and reminded me of the idea (if she spots this maybe she'll be kind enough to chime in here?).
I can't recommend any background reading because I can't recall coming across any substantial motivations for it, I can only share my current thinking:
Could you elaborate/enlighten me in terms of what you see as potential negatives? Is it just that you feel it's unnecessary?
I did look into the issue of testing the testing and it's not trivial. Given that I'm ok with foregoing testing of this for now. I did some checks locally and it seems fine.
I don't know where the earlier errors you referenced are coming from though. Did you check that your
exercism_path variable hasn't been reset or overwritten in the process of running the other utils/API tests? I think I still have work to do there to clean that up further...
No, it's not just that, see the IMHO above. I'm also deriving this stance from this warning against producing "simple, expedient, disposable code that adequately addresses just the problem at-hand.".
True, and I'm not disputing the benefits. Just that they are not worth taking a step in an overall wrong direction. Wrong for the whole R ecosystem.
I think knowing about namespacing (and using it in combination with auto-completion) is synergistically useful in the long run. And thus worth teaching / demanding, instead of avoiding.
I hope it's all of them ;-D Otherwise, inconsistent prefixing would "tear down with the ass, what you've (tried to) build with the hands".
So would repeatedly used package and function names ;-)
Yes, maybe they are, but is it helpful in the long run to train people to rely on the auto-complete pop-up rather than the docu / help pages? I think it's overall better to incentivize the latter. If that needs optimising, it's a task for the IDE developers.
I don't think that should be our goal. Optimising for the mechanisms at hand (function list in the help pages, pkg & function name completion, auto-completion pop-up in RStudio) should be. The function names are (and should continue to be) clear about what they do. Mixing in a mnemonic prefix detracts from that.
Effectively, I'm not going to block this quick, expedient change (already committed it locally, actually), but these are my arguments against actually doing it. Essentially: it would be training wheels that are only mildly useful and eventually problematic.
Maybe R needs a mechanism to
Dear @jennybc, I respect your work greatly, learned a lot from your teaching material and
Asked to comment by @jonmcalder. I agree with @katrinleinweber and pretty much all the arguments brought up above (which I don't need to repeat explicitly). One of the things that should be avoided pretty much at any cost in programming IMO is redundancy and duplication. I think this is promoted with a style like
I know this is an extreme example, the overlap is not 100% usually. Maybe we should make a comparison with Python, where a variety of import options are available.
import pkg_a import pkg_a as a from pkg_a import fun_a
R has (currently) only two for exported functions
library("pkga") fun_from_a() # or pkga::fun_from_a()
So we can't do something like
alias_namespace("numpy", as = "np") np::fun_from_np()
I think that would be neat. Anyone eager to implement that (if possible at all)?
In addition, if one wants to adhere to the tidyverse style guide:
As far as new users go, I think
So @jonmcalder as far as your renaming goes, I think it may be desirable for the function names to be a bit more verbose. So instead of
etc. why not using
I know that might be understood as contradicting to what I said above, but I think in your case it is fine if you have a suffix that contains a fraction of the package name because it has something to do with what the command does - and not primary with the name of the package. In particular, the command preserves a verb-like character.
I think it depends also a bit on how the package is used. E.g. with
I have no feelings (or maybe slightly positive ones) about