On Tuesday, April 28, 2015 at 11:38:34 PM UTC+10, Scott Jones wrote: > > > > On Monday, April 27, 2015 at 6:40:50 PM UTC-4, [email protected] wrote: >> >> >> >> On Sunday, April 26, 2015 at 8:24:15 PM UTC+10, Scott Jones wrote: >>> >>> Yes, precisely... and I *do* want Julia to protect the user *in that >>> case*. >>> If a module has functions that are potentially ambiguous, then 1) if the >>> module writer intends to extend something, they should do it *explicitly*, >>> exactly as now, and 2) Julia *should* warn when you have "using" package, >>> not just at run-time, IMO. >>> I have *only* been talking about the case where you have functions that >>> the compiler can tell in advance, just by looking locally at your module, >>> by a very simple rule, that they cannot be ambiguous. >>> >> >> The issue is that, in the example I gave, the compiler can't tell, just >> by looking at your module, if that case exists. It has to look at >> everything else imported and defined in the users program, and IIUC with >> macros, staged functions and lots of other ways of defining functions that >> can become an expensive computation, and may need to be delayed to runtime. >> >> Cheers >> Lex >> > > To me, that case is not as interesting... if you, the writer of the > module, want to use some type that is not defined in your module, then the > burden should be on you, to explicitly import from the module you wish to > extend... (Base, or whatever package/module the types you are using for > that function are defined)... >
I was only talking about the *user* of your module, not you the writer. The user is the one that lives in the big world where other packages use the same name, not the package writer in their insulated little module :) > > I'm only concerned about having a way that somebody can write a module, > and guarantee (by always using a specific type from the module) that the > names it wants to export cannot be ambiguous with other methods with the > same name. > If your methods were joined with any external methods of the same name whenever the user used your module with another using the same name, your methods would be dispatched to, since they use a concrete type, as you want. But that would "steal" dispatches from methods with more general signatures defined in the other module. That may break the other module, so the compiler doesn't do it by default to protect the user. But its what you want if you are extending a function, and you can say so explicitly as you mentioned above.
