On Sunday, April 26, 2015 at 1:41:24 PM UTC-4, Jeff Bezanson wrote: > > I keep getting accused of insisting that every name have only one > meaning. Not at all. When you extend a function there are no > restrictions. The `connect` methods for GlobalDB and SQLDB could > absolutely belong to the same generic function. From there, it's > *nice* if they implement compatible interfaces, but nobody will force > them to. > > Scott, I think you're overstating the damage done by a name collision > error. You can't expect to change package versions underneath your > code and have everything keep working. A clear, fairly early error is > one of the *better* outcomes in that case. >
I'm talking about cases where somebody has purposefully designed a package as a drop-in replacement for another (like TokuMX for MongoDB), so yes, I would expect to change things under my code and expect things to keep working. > In your design, there are *also* situations where an update to a > package causes an error or warning in client code. I'll grant you that > those situations might be rarer, but they're also subtler. The user > might see > > Warning: modules A and B conflict over method foo( #= some huge signature > =# ) > Again, I am only talking about methods where the signature includes a type from the module it is defined in... the compiler should be able to detect that when compiling the module, and provide that information so that NO extra checking needs to be done when `using` the module... wouldn't that speed things up? > What are you supposed to do about that? > > It's worth pointing out that merging functions is currently very > possible; we just don't do it automatically. You can do it manually: > > using GlobalDB > using SQLDB > > connect(c::GlobalDBMgr, args...) = GlobalDB.connect(c, args...) > connect(c::SQLDBMgr, args...) = SQLDB.connect(c, args...) > Why should I have to write a bunch of extra code, just to handle something the compiler should have been smart enough to figure out? (that it is impossible for the methods to conflict)... This will perform well since such small definitions will usually be > inlined. > That does not perform well from the viewpoint of the cost of the programmer's time... > If people want to experiment, I'd encourage somebody to implement a > function merger using reflection. You could write > > const connect = merge(GlobalDB.connect, SQLDB.connect, > conflicts_favor=SQLDB.connect) > Scott
