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

Decision on export of Base modules names #3924

Closed
kmsquire opened this issue Aug 2, 2013 · 2 comments
Closed

Decision on export of Base modules names #3924

kmsquire opened this issue Aug 2, 2013 · 2 comments

Comments

@kmsquire
Copy link
Member

kmsquire commented Aug 2, 2013

As pointed out by @nolta here, the exports in Sort are imported into Base with importall, and the majority of those are reexported by Base.

There are some unexported functions, but use of them should be rare, so it seems reasonable not to export Sort itself from Base, and anyone who needs Sort can import Base.Sort.

  1. Do people agree that this is reasonable?
  2. If so, there are a host of other modules (below) in the same situation. Which of these, if any, should be exported from Base?

Obvious modules meant to be used with the module name include Pkg, Pkg2, and Profile; these should still be exported. Others?

readlines(open("sysimg.jl"),strip) |> 
           x->filter(y->beginswith(y, "importall"),x) |> 
           x->[split(y)[2][2:end] for y in x] |>
           x->filter(y->isdefined(symbol(y)),x)
11-element Any Array:
 "Math"        
 "Random"      
 "Order"       
 "Sort"        
 "SparseMatrix"
 "LinAlg"      
 "DSP"         
 "GMP"         
 "MPFR"        
 "QuadGK"      
 "Profile"     
@nolta
Copy link
Member

nolta commented Aug 2, 2013

Beat me too it ;)

Yes, i say we stop exporting these modules, if possible.

@StefanKarpinski
Copy link
Sponsor Member

The common usage of the sorting and ordering APIs don't require access to these modules anymore, so yes, we should stop exporting these. I mostly didn't change things because I wasn't sure about a smooth deprecation strategy but maybe we should just not export them and let people fix their code when it breaks.

@nolta nolta closed this as completed in 85ecfb6 Aug 6, 2013
nolta added a commit that referenced this issue Aug 6, 2013
RFC: unexport a bunch of Base modules (closes #3924)
staticfloat pushed a commit that referenced this issue Jun 18, 2024
Stdlib: Pkg
URL: https://github.com/JuliaLang/Pkg.jl.git
Stdlib branch: master
Julia branch: master
Old commit: 78bca4227
New commit: 8c996799b
Julia version: 1.12.0-DEV
Pkg version: 1.12.0
Bump invoked by: @DilumAluthge
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaLang/Pkg.jl@78bca42...8c99679

```
$ git log --oneline 78bca4227..8c996799b
8c996799b Fix HistoricalStdlibVersions install to version (#3930)
db8ce8919 update docs for test in REPL (#3924)
7f6eb8b8e avoid returning empty completion when aborting to not have it inline complete directories (#3917)
```

Co-authored-by: Dilum Aluthge <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants