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