Reserving names in Base

[Per]

@foobar_lv2

If no suitable name / abstract interface exists in Base, then, well, as far as I understood there needs to be a fooBase package

This is not strictly true. Even if there is no foo in Base, I can still do

@eval Base foo(x::MyType) = ...

which will extend the function Base.foo for MyType, or create it if it did not exist.

I’m not saying this is a good idea, I’m just saying it is possible, so there’s no need to pre-emptively reserve names.

@foobar_lv2

Even having a Misc stdlib with submodules like Misc.geometry is enough for having a coordination point for package authors (that is not fooBase with the possibility of competing fooBase s ).

This is ultimately a question of who will do the maintenance work. Something that goes into a standard library would ultimately be maintained by the core Julia team, while competing fooBase packages can be maintained by anyone. While I believe that the core team would do an excellent job, I also suspect that they need to eat and sleep sometimes, just like mortals. So the best approach might be to first develop fooBase independently and then once it is stable, and if it reaches wide adoption, politely ask if they would consider taking ownership.

[Tamas_Papp]

Also, putting things in Base also implies changes at the release frequency. Packages can be much more agile.

@Per

I also suspect that they need to eat and sleep sometimes, just like mortals.

While I am not suggesting that this is necessarily true, I also heard that some of them also have jobs.

[chakravala]

Perhaps a package in stdlib?

[kristoffer.carlsson]

Perhaps a package outside stdlib?

[fredrikekre]

@kristoffer.carlsson

Perhaps a package outside stdlib?

Thats a good idea, perhaps something like *Base packages, which is common in e.g. the Julia Language. Maybe we can adopt that pattern? Some examples:

• StatsBase
• DiffEqBase
• NLSolversBase
• OnlineStatsBase
• RecipesBase
• MathProgBase
• …
  

[ScottPJones]

@fredrikekre

Thats a good idea, perhaps something like *Base packages, which is common in e.g. the Julia Language . Maybe we can adopt that pattern? Some examples:

Actually, I think an even lower level might be better for this.

I made a separate StrAPI.jl that has just the API (empty functions and trait definitions), using ModuleInterfaceTools.jl to simplify the task of a number of packages implementing different composable pieces of a common API.

StrBase.jl and ChrBase.jl then extend the functions, and set up the basic types (Str and Chr), and add the appropriate traits for the “built-in” Str and Chr types (i.e. ASCIIChr, LatinChr, UCS2Chr, UTF32Chr, ASCIIStr, LatinStr, UCS2Str, UTF32Str, UTF8Str, UTF16Str, and a few more such as BinaryStr).

Doing that way, I think allows more flexibility for other packages that implement the API, but don’t want to use the basic types/functions defined in the *Base packages.

[jlperla]

@fredrikekre

Thats a good idea, perhaps something like *Base packages,

When types are required to be coordinated, a *Base is necessary and the various packages can work together to ensure they have the right structure. You can’t second-guess what that would look like.

… but if most of this is just about method merging, why not tackle that more head-on? In the absence of a long-run solution to having methods stay in their own namespaces, why not start with approved @merge macro, etc. to make things easier?