On Friday, May 1, 2015 at 11:39:20 PM UTC+10, Tom Breloff wrote: > > I agree that auto-merging could cause hard-to-find bugs for the user. > This is less important than causing impossible-to-find bugs for a package > writer IMO. >
I'm not sure I understand what impossible to find bug not merging functions causes. > > Here's a couple potential solutions for the user space issues: > > - "@verbose using SomeHugeModule" > - this could analyze the exported functions and check for name > clashes superficially (i.e. no concept of dispatch types) and print a > report of potentially dangerous method names > - new syntax: "using SomeHugeModule without fragileMethod1, > fragileMethod2" > - similar to "import A: x, y" but the reverse... allow everything > except those 2 methods to be imported > > Note that for a user that just wants to use a module without worrying > about safety, nothing changes. However for users building more complex > systems with many packages, they have a way to see potential clashes and > decide on their own how best to handle them. A "using ... without ..." > syntax would be super nice for some larger packages that mostly have unique > names exported, but may have a couple clashes. Then you can do "using" and > just add to the "without" list if any clashes become a problem. > The "without" syntax allows possible reductions in verbosity when excluding a few names from the import, and makes them visible, so it is useful, but it is only syntactic sugar, not any new solution. > > > And here's an idea for the package writer issue: > > @includes_private Module A > > f(x) = "not too important" > _f(x) = "important... must call this internally" # NOTE: the underscore > tells the @includes_private macro to "hide" this function from the outside > world > > function g() > bigobj = createHugeObject() > f(bigobj) > _f(bigobj) # we should be able to guarantee that this calls our > function above... even if someone defines A._f(x) elsewhere > end > Julia experts should correct me, but it is my understanding that within the module it will always call the definition local to the module (unless you import explicitly). To quote the manual "Within a module, you can control which names from other modules are visible (via importing)". > > > end > > using A > f(x) = "something orthogonal to A.f" > A._f(x) = "something else" # NOTE: this should either not be allowed > (hard) or at least not clash with A's _f(x)... maybe replacing _f with a > gensym within A?? > g() > > > I *think* these solutions are somewhat straightforward, and the only > thing that would change core julia is the "without" syntax. If changing > syntax is not worth it, maybe you could make a "using_without" macro? > I don't really understand what the @include_private macro does and what problem it solves. Just don't export _f(). > > @using_without SomeHugeModule fragileMethod1 fragileMethod2 > > And now that I think about it, you could combine these concepts into > another macro which would analyze for name clashes and add any potentially > dangerous method names to the without list: > > @safe_using SomeHugeModule > > > > Does this functionality exist already? Are these macros something the > community would want? I would be willing to work on it. > > > >
