-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Redefining how to identify operating systems #22214
Comments
The hierarchy approach in OperatingSystems.jl is pretty nice. I can even see writing dispatch-based code for certain system-specific things. |
One example that comes to mind for dispatching on the OS is BinDeps. |
Even if we add |
One option on this front would be to keep the iswindows() = Sys.OS <: Sys.Windows That provides a concise way to condition on the OS inside of functions or programs while at the same time allowing a hierarchical type-based approach that can be used for dispatch purposes. Does that seem like a good idea, or would it be bad to have two ways of expressing the same thing? |
Feels over-designed to me |
Fair point. What's your preference, @vtjnash? Just |
Once upon a time, the current operating system was identified and conditioned on via
@<os>_only
macros. Eventually these were replaced withis_<os>
functions in #16219. However, these 5 functions differ from the rest of Base in that there are 74 Base functions that begin withis
and only 6 (including these 5) that begin withis_
. (In case you're wondering, the one other misfit isis_assigned_char
.) This is a very unfortunate inconsistency. Thus I opened #22182 to rename these to match the rest of Base. That is,is_<os>
->is<os>
.A discussion started up in that PR regarding an alternative way to identify and condition on operating systems. In particular, one idea was to define separate types for each operating system, with subtyping to show that a given OS is Unix-based, for example. I made a prototype of this in OperatingSystems.jl.
Now, the purpose of this issue is to discuss the possibility of an alternative design, should we decide it's worth the churn. As I've said in #22182, the only change I think is necessary is to remove the underscore, but I figured it's worth having a wider discussion on how best to address this.
The text was updated successfully, but these errors were encountered: