Scott-- yes! If BetterA imports and extends a function from A, it is exactly the same function object. A.func and BetterA.func will be identical. Problems only enter if A and BetterA were developed in total isolation, and the authors just happened to pick the same name.
The way to go here would be to have the DocumentDB module define an interface, and then both MongoDB and TokuMX extend it. What I don't get is that elsewhere in your argument, you seem to say that coordinating and agreeing on an interface is a non-starter. But I just don't see how you could talk to both MongoDB and TokuMX with the same code unless they agreed on an interface. Now consider `connect`. This might be common to both DocumentDB and SQLDB. Is it similar enough that it should go in an even more abstract interface GeneralDB? I'm not sure, but I think this is exactly the kind of interface design process that happens in any OO language. In Java, you can have a `connect` method whether or not you implement a `Connectable` interface. But only if you explicitly refer to the Connectable interface will you be able to work with code that requires it. I think the same kind of thing is happening here. You can just write a `connect` function, or you can say `import Connectable.connect` first, in which case you will be extending the "public" `connect` function. On Sun, Apr 26, 2015 at 12:25 AM, <[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? >> >
