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