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? > >
