On Sat, Apr 25, 2015 at 12:30 PM, Michael Francis <[email protected]> wrote:
> Stefan, my takeaways from what you are saying are as follows. > > 1) dynamic dispatch doesn't work without the potential for surprising > ambiguities in a mixed namespace environment. The more modules included the > worse this gets. > The issue here is not dispatch – it's deciding what global bindings refer to. Only if you merge generic functions upon import does naming get mixed up with dispatch, which we haven't done and I've argued would lead to various problems. The way things now work, naming and dispatch are completely orthogonal. > 2) A good practice would be to import no functions from modules I don't > own into modules I do and explicit qualify all access to external modules > from day one. I can't afford to simply break one day. > You can completely prevent any surprises if you have tests that exercise every global binding that occurs anywhere in your code. That's a fairly straightforward coverage metric and one that's not unreasonable to insist on keeping at 100% in production-quality code. It is much easier to satisfy than perfect test coverage: if you have many functions that use `foo` you only need one test that calls `foo` somehow to be sure that `foo` is an unambiguous reference. We should implement this metric: https://github.com/JuliaLang/julia/issues/11006 > 3) inside my own namespace, modules continue to use exports but I have to > implement SuperSecretBase modules managing my function collapses. (Or > minimize the use of modules) > I don't follow. Is this still about ambiguity of global bindings? > 4) throwaway scripts can continue to work as before but risk breakage as > new functions are exported. > Yes – anything that gets bindings via `using`, doesn't fully qualify them, and isn't tested for unambiguous global name resolution could potentially break.
