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.
Scott On Sunday, April 26, 2015 at 5:46:15 AM UTC-4, [email protected] wrote: > > > > On Sunday, April 26, 2015 at 7:23:02 PM UTC+10, Scott Jones wrote: >> >> Ah, but that is NOT the situation I've been talking about... If the >> writer of a module wants to have a function that takes ::Any, and is not >> using any other types that are local to that package, then, from the rules >> I'd like to see, they *would* have to explicitly import from Base (or >> whichever module they intended to extend). >> > > Neither module is extending anything, they are separate. Its the user > that wants to use them both in the same program, and its the user that > Julia is protecting. > > Cheers > Lex > > > >> >> Scott >> >> On Sunday, April 26, 2015 at 12:25:28 AM UTC-4, [email protected] wrote: >>> >>> The situation I was describing is that there is: >>> >>> module A >>> type Foo end >>> f(a::Any) ... >>> f(a::Foo) ... >>> >>> which expects f(a) to dispatch to its ::Any version for all calls where >>> a is not a Foo, and there is: >>> >>> module B >>> type Bar end >>> f(a::Bar) ... >>> >>> so a user program (assuming the f() functions combined): >>> >>> using A >>> using B >>> >>> b = Bar() >>> f(b) >>> >>> now module A is written expecting this to dispatch to A.f(::Any) and >>> module B is written expecting this to dispatch to B.f(::Bar) so there is an >>> ambiguity which only the user can resolve, nothing tells the compiler which >>> the user meant. >>> >>> Cheers >>> Lex >>> >>> >>> On Sunday, April 26, 2015 at 12:00:50 PM UTC+10, Michael Francis wrote: >>>> >>>> I don't think Any in the same position is a conflict. This would be >>>> more of an issue if Julia did not support strong typing, but it does and >>>> is >>>> a requirement of dynamic dispatch. Consider >>>> >>>> function foo( x::Any ) >>>> >>>> Will never be chosen over >>>> >>>> Type Foo end >>>> >>>> function foo( x::Foo ) >>>> >>>> As such I don't get the argument that if I define functions against >>>> types I define they cause conflicts. >>>> >>>> Being in the position of having implemented a good number of modules >>>> and being bitten in this way both by my own dev and by changes to other >>>> modules I'm very concerned with the direction being taken. >>>> >>>> I do think formalization of interfaces to modules ( and behaviors) >>>> would go a long way but expecting a diverse group of people to coordinate >>>> is not going to happen without strong and enforced constructs. >>>> >>>> As an example I have implemented a document store database interface, >>>> this is well represented by an associative collection. It also has a few >>>> specific methods which would apply to many databases. It would be nice to >>>> be able to share the definition of these common interfaces. I don't >>>> advocate adding these to base so how should it be done? >>>> >>>>
