Manual Inclusion in `__init__`, an alternative to `@postinit`

[SBuercklin]

Rather than forcing an implementation of __init__ on the user and having them opt into their own __init__ with @postinit, could you instead expose a function which has a method implementation for each module, and the user manually include that in their __init__? This is the approach that BinaryTraits.jl takes, reference here.

I think this would be much less disruptive to users workflows than having them restructure their existing __init__s per package.

I really like the idea that this package enforces the presence of fields as part of an interface, that's an issue I've not found a good solution for, and this looks promising. Thanks for the contribution!

[mind6]

Initially there was an option to not generate any init. But it's quite complicated to find a supertype's module in some situations. So I'm using init to setup the lookup table for the loaded module based on its fullname(...)

To allow manual checking, I'd need to build up a dynamic route map depending on how a set of modules was loaded.

[mind6]

I could have @postinit mangle the name of the function a bit, so all you'd need to do is prepend @postinit to your existing init with no other changes.

But name mangling can create confusion. It's better to explicitly change the name:

original code

function __init__()
...
end

with Inherit.jl

using Inherit
@postinit function __myinit__()
...
end

Another reason not to mangle is it cannot prevent Inherit.jl's init from being overwritten, if the user manually defines her own init outside of @postinit.

[mind6]

some other possible solutions if enough people are concerned about clobbering of init

solution	good	bad
provide a manual "check module" function; have the option to not generate init	the user has full control	if the function is not called by the user, interfaces may be left unimplemented. Also, client modules may not work correctly at all.
the above but implement dynamic discovery of supertype module object	if user doesn't call the check function, client modules should still work	complex. benefits of manual checking not quite clear
throw an exception when Inherit.jl detects presence of __init__	reduces silent clobbering	cannot eliminate all silent clobbering, i.e. user defines it after Inherit.jl macros execute. may mislead the user to think clobbering cannot happen.
factor out @postinit into a separate module that allows multiple init registrations. Verify that modules loaded after it do not have their own definitions of __init__ (using techniques from Revise.jl?)	have a central place to manage multiple inits. Prevents silent clobbering altogether.	complex