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
Move File and IO::FileDescriptor's platform-specific parts to Crystal::System #5333
Hopefully the third time lucky we'll manage to merge an IO portability refactor.
I've copied the commit messages out below so people actually read them. I also suggest you review each commit in order, instead of reviewing the diff as a whole. it makes the entire thing a lot more readable and understandable.
Make IO::FileDescriptor fcntl private
fcntl() is an extremely low-level platform-specific detail which should only be used internally to IO::FileDescriptor. In this commit, it is removed from the public API and made private.
The only usage of this API was added only recently, in Crystal::Main. It is replaced with a method which calls LibC.fcntl directly, since it is too early in init to create a new IO::FileDescriptor instance directly and ask it if it's blocking.
Separate platform-specific parts of IO::FileDescriptor
In order to add windows support to Crystal, IO::FileDescriptor cannot depend on posix APIs. Here, we refactor out the platform-specific parts of IO::FileDescriptor into a mixin module in Crystal::System. Some platform-specific methods are refactored out of methods which contain both platform-specific and cross-platform behaviour. These methods are prefixed with
Make Tempfile inherit File
Making Tempfile inherit from File allows the instance to be passed to methods which expect File, and makes Tempfile much more powerful. This requires adding a new private constructor to File which sets @path and calls super.
Separate platform-specific parts of File
Similar to previous patch: Separate platform-specific parts of IO::FileDescriptor.
I think there needs to be a proper support for platform-specific functionality in the stdlib. IMHO, throwing stuff out like
Truth is, programs tend to need platform-specific stuff that's not yet nicely wrapped. I doubt that you'll be able to offer everything that the control functions support in an agnostic manner. And many programs are fine if they don't work on some random platform, as long they work where they're intended to be used. Diminishing all API to the most common denominator will only hurt on the long run.
Outside the scope of this PR, I'd actually like to see a documentation flag to note platform information right in the in-source docs. The docs generator could then mark such a section visually, or add a "Tag badge" to it.
I'm not sure mixins are better than composition, but that should really help going forward, so I'm gonna say
I don't think we need the
Mixin suffix when naming modules, I mean
include Crystal::System::FileDescriptor is just fine, and the filenames don't have the
_mixin suffix anyway (
About platform-specific methods, there are usages of the
_impl suffix in different places in the stdlib. Maybe we could stick to that? My point is that "private impl" can englob the "target-specific" meaning.
Hum, I prefer to use
Fairly minor, but it looks better to my eyes.
There have been loads of great ideas about refactoring
If people feel that some of that work would be better in this PR however, i'm happy to include it.