-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Move File.readable?
, .writable?
, .executable?
to File::Info
#14484
Move File.readable?
, .writable?
, .executable?
to File::Info
#14484
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering about the policy around deprecated methods and their documentation: shall we keep the doc comment, only have the Deprecated annotation, add a See Type#method
link (which maybe the Deprecated annotation could handle)?
It's probably best to keep the current documentation. The method still works like that and deprecation is just a friendly indicator for future changes. The deprecation message typically refers to the replacement (which is implicitly linked). So there's no need for an explicit |
This pull request has been mentioned on Crystal Forum. There might be relevant details there: https://forum.crystal-lang.org/t/add-file-info-methods-to-path/6781/1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought I had approved this PR already.
Though there should just be a few fixes to use the non deprecated calls then fix/upgrade the markd shard
These methods provide lower-level insights into the file system. Their use cases are rare and exposure in the top-level
File
namespace is confusing due to the similarly-named methodsFile.read
andFile.write
.Resolves part of #14245