-
-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
masking S4 methods #81
Comments
I 100% agree with you that it's very bad to have functions with the same names as |
You can do the same as you did with Or, if you do not want to change the current behavior, adding warnings in README and emphasizing the use of Indeed, there is a trade-off between how many of the current users use these functions without running into issues vs how many users (current or new; Bioconductor uses S4!) are / will be exposed to the strange side-effect behavior. Since we cannot quantify the trade-off, the decision is subjective. |
Even with colour picker I was hesitant and asked on Twitter how I should handle it. But it was a much easier decision because it doesn't have THAT many users, and also it's more used in interactive environments, whereas show/hide are used inside packages that many people use so it'll have a very big impact. show/hide are the "flagship" functions and I'm really afraid to break functionality for a lot of people. But I do see your point.... if I were to change them, do you have any reasonable suggestions to what they can be changed? show+hide just make the most intuitive sense in my opinion |
To follow your coding style, I suggest Playing with fire, there is For |
Ok, thanks for your suggestions. I can promise you that in the coming weeks I won't be changing anything because I have too many other things going on, but I do promise I'll give it some thought..... :) Not the response you were looking for, but hopefully better than nothing! I'll ask more people and get more opinions |
Thank you! |
@MikeBadescu I've added synonyms for all the show/hide/addClass/etc functions, and mention them at the top of the corresponding function documentation. I really don't think I'll ever remove existing functions, especially the hide/show since they're the flagship functions and are used in so much code. I hope this compromise is sufficient |
Thank you! |
Since you got me thinking about your solution for the default values (#80), would it make sense to add warning messages for shinysj functions that have the same name as S4? As in, when |
Since you bring it up again, I do think I should add a note to the documentation that mentions this. I'm a little hesitant to show a message in the console because it's such a widely used function and an extremely small fraction of people run into this masking issue. As you can guess, I'm even less comfortable with the idea of deprecating the show/hide functions at any point in the future, because it will be chaos for a lot of apps. Do you think it's ok if I just make a note in the function doc that says "if you use S4 classes or see weird behaviour when using 'show()' then you should try using 'showElement()' instead"? |
Sur,e that would help and it is the place where people would look. |
Referencing #15, I suggest renaming
show
andremoveClass
. While the Rshow
issue seems to be fixed in R 3.3.1, there still is a problem ifshinyjs
is loaded.In the code below, both
show
andremoveClass
fail whenshinyjs
is loaded but work as expected if we comment out the first line. Loadingshinyjs
should not interfere with S4 functionality.The text was updated successfully, but these errors were encountered: