[ANN] InlineExports.jl

Package Announcements
1

I would like to announce a tiny package called InlineExports.jl. It provides a single macro, @export, which allows you to export variables, functions and types at their points of definition. This is best illustrated by an example:

module M
using InlineExports

@export function f(x)
    return x^2
end

@export const answer = 42
@export my_string = "Banana"

end

Any comments or feedback is much appreciated!

10 Likes
2

FWIW I rather like seeing the list of exports at the top of a package rather than being interleaved with the function/value definitions. I know in an ideal world that info would be easily accessible in the docs, but often it ends up being easier to glance at the top-level src/SomePackage.jl file to see what’s exported.

Others may have diverging opinions, of course.

6 Likes
3

I agree wholeheartedly for most packages! :blush: But when working on private projects or during development, I have found myself putting export statements above function definitions, etc. where, in a lot of cases, inline exports actually made more sense. There was some discussion about this in: export keyword in front of functions / types · Issue #8005 · JuliaLang/julia · GitHub

Edit: And if you want a list of exported names, there is also Base.names(::Module).

1 Like
4

Makes sense. And sorry for starting out with criticism right out of the gate. It’s a cool package - the way you used Symbol to create a macro with a reserved word as a name is pretty clever.

Also thanks for the pointer to Base.names, that seems useful.

1 Like
5

This is a violation of DRY, as you need to write the exported symbol one extra time. For packages which span many files, keeping this consistent requires some effort, which InlineExports.@export makes unnecessary, so I will be very happy to use it.

Also, note that some packages don’t export the API — this is also a valid style for Julia.

7 Likes
6

Whether this package is useful depends, on the use case.
Some interops would be placed at several distinct modules for the sake of better code organizationm, and InlineExports.jl could be useful when it comes to export something from an internal module to another(also internal).
Also, the top-level module that describes which APIs to be exported to users, would better not to use @export.