Skip to content
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

Closed
ararslan opened this issue Jun 4, 2017 · 6 comments
Closed

Redefining how to identify operating systems #22214

ararslan opened this issue Jun 4, 2017 · 6 comments
Labels
design Design of APIs or of the language itself filesystem Underlying file system and functions that use it speculative Whether the change will be implemented is speculative

Comments

@ararslan
Copy link
Member

ararslan commented Jun 4, 2017

Once upon a time, the current operating system was identified and conditioned on via @<os>_only macros. Eventually these were replaced with is_<os> functions in #16219. However, these 5 functions differ from the rest of Base in that there are 74 Base functions that begin with is and only 6 (including these 5) that begin with is_. (In case you're wondering, the one other misfit is is_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.

@ararslan ararslan added design Design of APIs or of the language itself filesystem Underlying file system and functions that use it speculative Whether the change will be implemented is speculative labels Jun 4, 2017
@StefanKarpinski
Copy link
Sponsor Member

The hierarchy approach in OperatingSystems.jl is pretty nice. I can even see writing dispatch-based code for certain system-specific things.

@ararslan
Copy link
Member Author

ararslan commented Jun 5, 2017

One example that comes to mind for dispatching on the OS is BinDeps.

@stevengj
Copy link
Member

stevengj commented Jun 5, 2017

Even if we add os() <: OS.Windows in Base, I would still like the simplicity of iswindows(), since this is a pretty common check.

@ararslan
Copy link
Member Author

One option on this front would be to keep the iswindows() family of functions, but implement them as, e.g.

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?

@vtjnash
Copy link
Sponsor Member

vtjnash commented Jun 19, 2017

Feels over-designed to me

@ararslan
Copy link
Member Author

Fair point. What's your preference, @vtjnash? Just iswindows()?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design of APIs or of the language itself filesystem Underlying file system and functions that use it speculative Whether the change will be implemented is speculative
Projects
None yet
Development

No branches or pull requests

4 participants