
On Tue, 10 Dec 2013, Erik Hesselink wrote:
On Tue, Dec 10, 2013 at 3:36 PM, harry
wrote: Sven Panne-2 wrote
I think the rational is: If you carefully and explictly import only the things you need, the new version won't break your build. Importing whole modules can of course break your build when new entities have been added to the imported module, but this could be avoided by being less lazy and more explicit. ;-) Changing e.g. a signature or removing stuff OTOH will break some builds in ways which can't be anticipated.
Fixing that took considerably less time than what I would have spent on making all my imports explicit. Laziness wins again :)
True :) Although I have noticed that when you use explicit or qualified imports, the code is much more easily readable for others, since it's always clear where an identifier comes from. That might be a reason to use this style for some code. I've often developed without explicit imports, and added them when 'done'. Then later, when altering the code, I can remove the explicitness again while developing, adding it back at the end. That flow could use some tool support, though.
The decision whether to use qualification or not, cannot be done when importing, it must be done when exporting. If you define writeChan, then it is certainly not intended to use it as Chan.writeChan. Vice versa, if module Chan exports "write" then it calls for name clashes if you import that implicitly and unqualified. For that reason I use qualified style whereever possible (i.e. except for infix operators) and define names such that they make sense together with the qualification. This way I need neither interim solutions nor tool support.